Tipi di test software
Test unitari
Il test unitario viene eseguito su una singola funzione, classe o modulo indipendentemente rispetto al test di un software completamente funzionante. Utilizzando un framework per i test unitari, il programmatore può creare casi di test con input e output previsto. Quando ne hanno centinaia, migliaia o decine di migliaia di casi di test unitari per un grande progetto software assicura che tutte le singole unità funzionino come previsto mentre si continua a modificare il codice. Quando si modifica un'unità con casi di test, i casi di test per quel modulo devono essere studiati e determinare se sono necessari nuovi casi di test, l'output è cambiato o i casi di test corrente possono essere rimossi come non più rilevanti. La creazione di un grande volume di test unitari è il modo più semplice per ottenere una copertura dei casi di test elevati per una base di codice software, ma non garantirà che il prodotto finale funzioni come sistema come previsto.
Test funzionali
Il test funzionale è la forma più comune di test. Quando le persone si riferiscono ai test del software senza molti dettagli, spesso significano test funzionali. I test funzionali controlleranno le funzioni primarie del lavoro del software come previsto. Potrebbe essere scritto un piano di test per descrivere tutti i casi di test funzionali che verranno testati, il che corrisponde alle principali caratteristiche e capacità del software. Il test della funzionalità primaria sarà "percorso felice " Test, che non cerca di rompere il software o utilizzarlo in scenari difficili. Questo dovrebbe essere il minimo assoluto di test per qualsiasi progetto software.
Test d'integrazione
Dopo il test unitario e il test funzionale, potrebbero esserci diversi moduli o l'intero sistema che non è stato ancora testato nel suo insieme. O potrebbero esserci componenti che sono in gran parte indipendenti ma occasionalmente usati insieme. Ogni volta che i componenti o i moduli vengono testati in modo indipendente ma non come un intero sistema, è necessario eseguire test di integrazione per convalidare la funzione dei componenti come un sistema di lavoro in base ai requisiti e alle aspettative dell'utente.
Test di stress
Pensa ai test di stress come se stessi testando una navetta o un aereo spaziale. Cosa significa mettere il tuo software o sistema sotto "stress"? Lo stress non è altro che un carico intenso di un tipo specifico che è più probabile che rompa il sistema. Questo potrebbe essere simile ai "test di carico" nel senso di mettere il tuo sistema in concorrenza elevata con molti utenti che accedono al sistema. Ma sottolineare un sistema potrebbe accadere anche su altri vettori. Ad esempio, l'esecuzione del firmware su un componente hardware quando l'hardware ha avuto un deterioramento fisico e funziona in modalità degradata. Lo stress è unico per tutti i tipi di software e i sistemi e la progettazione di stress test dovrebbero essere considerati quali cause naturali o innaturali hanno maggiori probabilità di sottolineare il tuo software o il tuo sistema.
Test di carico
Il test di carico è un tipo specifico di test di stress, come discusso sopra, per cui un gran numero di connessioni e accessi concorrenti dell'utente sono automatizzati per generare la simulazione dell'effetto di un gran numero di utenti autentici che accedono allo stesso tempo. L'obiettivo è scoprire quanti utenti possono accedere al tuo sistema contemporaneamente senza la rottura del sistema software. Se il tuo sistema può facilmente gestire il traffico normale di 10.000 utenti, cosa accadrà se il tuo sito Web o software diventa virale e ottiene 1 milione di utenti? Sarà inaspettato "CARICO" Rompi il tuo sito Web o sistema? I test del carico lo simuleranno, quindi ti senti a tuo agio con il futuro aumento degli utenti perché sai che il tuo sistema può gestire il carico aumentato.
Test delle prestazioni
Le persone possono diventare assolutamente frustrate e disperare quando il software non soddisfa i loro requisiti di prestazione. Le prestazioni, in generale, significa quanto velocemente possono essere completate funzioni importanti. Più complesse e dinamiche le funzioni sono disponibili in un sistema, più è importante e non ovvio per testare le sue prestazioni, prendiamo un esempio di base, Windows o Linux Operating System. Un sistema operativo è un prodotto software altamente complesso e fare test sulle prestazioni sul suo sistema potrebbe comportare la velocità e la tempistica di funzioni come l'avvio, l'installazione di un'app, la ricerca di un file, l'esecuzione di calcoli su una GPU e/o qualsiasi altra i milioni di azioni che possono essere eseguite. È necessario prestare attenzione durante la selezione dei casi di test delle prestazioni, per garantire le caratteristiche delle prestazioni importanti e probabili per malfunzionamento testate.
Test di scalabilità
Il test sul tuo laptop è buono, ma non abbastanza buono quando stai costruendo un social network, un sistema di posta elettronica o un software supercomputer. Quando il tuo software dovrebbe essere distribuito su 1000 server, tutti funzionanti all'unisono, i test che eseguono localmente su un sistema non scopriranno i bug che si verificano quando il software viene distribuito "su scala" su centinaia di migliaia di istanze. In realtà, i tuoi test probabilmente non saranno mai in grado di funzionare su larga scala prima di rilasciare in produzione perché sarebbe troppo costoso e non pratico per creare un sistema di test con 1000 server che costa milioni di dollari. Pertanto, i test di scalabilità vengono eseguiti su più server, ma di solito non il numero completo di server di produzione per cercare di scoprire alcuni dei difetti che potrebbero essere trovati quando i sistemi vengono utilizzati su infrastrutture più grandi.
Test di analisi statica
L'analisi statica sta testando che viene eseguito ispezionando il codice software senza effettivamente eseguirlo. Per fare analisi statiche, in generale, useresti uno strumento, ci sono molti, uno strumento famoso è la copertura. L'analisi statica è facile da eseguire prima di rilasciare il software e può trovare molti problemi di qualità nel codice che possono essere risolti prima di rilasciare. Errori di memoria, errori di gestione dei tipi di dati, dereferenze puntatore nullo, variabili non inizializzate e molti più difetti possono essere trovati. Lingue come C e C ++ beneficiano notevolmente dell'analisi statica perché le lingue forniscono una grande libertà ai programmatori in cambio di grande potenza, ma questo può anche creare grandi bug ed errori che possono essere trovati utilizzando test di analisi statica.
Test di iniezione di guasti
Alcune condizioni di errore sono molto difficili da simulare o attivare, pertanto il software può essere progettato per iniettare artificialmente un problema o un errore nel sistema senza che si verifichino naturale. Lo scopo dei test di iniezione di guasti è vedere come il software gestisce questi guasti imprevisti. Risponde con grazia alla situazione, si schianta o produce risultati problematici inaspettati e imprevedibili? Ad esempio, supponiamo che abbiamo un sistema bancario e c'è un modulo per trasferire fondi internamente dal conto A al conto B. Tuttavia, questa operazione di trasferimento viene chiamata solo dopo che il sistema ha già verificato che questi account esistessero prima di chiamare l'operazione di trasferimento. Anche se supponiamo che esistano entrambi gli account, l'operazione di trasferimento ha un caso di errore in cui non esiste un conto di destinazione o di origine e che possa lanciare un errore. Perché in circostanze normali non otteniamo mai questo errore a causa del pre-test degli input, quindi per verificare il comportamento del sistema quando il trasferimento fallisce a causa di un account inesistente, iniettiamo un errore falso nel sistema che restituisce un account inesistente Per un trasferimento e testare come risponde il resto del sistema. È molto importante che il codice di iniezione di guasti sia disponibile solo negli scenari di test e non rilasciato in produzione, dove potrebbe creare il caos.
Test di sovraccarico della memoria
Quando si utilizzano linguaggi come C o C ++, il programmatore ha una grande responsabilità di affrontare direttamente la memoria e questo può causare bug fatali nei software se vengono commessi errori. Ad esempio, se un puntatore è nullo e dereferenziato, il software si bloccherà. Se la memoria viene assegnata a un oggetto e quindi una stringa viene copiata sullo spazio di memoria dell'oggetto, fare riferimento all'oggetto può causare un crash o persino un comportamento errata non specificato. Pertanto, è fondamentale utilizzare uno strumento per provare a catturare errori di accesso alla memoria nel software che utilizza lingue come C o C ++, che potrebbero avere questi potenziali problemi. Gli strumenti che possono eseguire questo tipo di test includono valgrind open source o strumenti proprietari come PurifyPlus. Questi strumenti possono salvare la giornata in cui non è chiaro perché il software si stia arrestando in modo anomalo o si comporta male e indicano direttamente la posizione nel codice che ha il bug. Fantastico, giusto?
Test del caso limite
È facile commettere errori nella codifica quando si è su quello che viene chiamato confine. Ad esempio, una macchina per cassiere automatizzata in banca dice che puoi prelevare un massimo di $ 300. Quindi, immagina che il programmatore abbia scritto il seguente codice in modo naturale quando costruisce questo requisito:
If (amt < 300)
startWithDrawl ()
altro
errore ("puoi prelevare %s", amt);
Puoi individuare l'errore? L'utente che cerca di prelevare $ 300 riceverà un errore perché non è inferiore a $ 300. Questo è un bug. Pertanto, i test di confine vengono eseguiti in modo naturale. I limiti dei requisiti assicurano quindi che su entrambi i lati del confine e sul confine, il software funziona correttamente.
Test fuzz
La generazione di input al software ad alta velocità può produrre quante possibili combinazioni di input, anche se tali combinazioni di input sono una assurdità totale e non sarebbero mai fornite da un utente reale. Questo tipo di test fuzz può trovare bug e vulnerabilità di sicurezza non trovati attraverso altri mezzi a causa dell'elevato volume di input e scenari testati rapidamente senza generazione di casi di test manuale.
Test esplorativi
Chiudi gli occhi e visualizza cosa significa la parola "esplorare". Stai osservando e sondando un sistema per scoprire come funziona veramente. Immagina di ricevere una nuova sedia da scrivania in ordine di posta e ha 28 parti tutte in sacchetti di plastica separati senza istruzioni. Devi esplorare il tuo nuovo arrivo per capire come funziona e come viene messo insieme. Con questo spirito, puoi diventare un tester esplorativo. Non avrai un piano di test ben definito dei casi di test. Esplorerai e sonderai il tuo software alla ricerca di cose che ti facciano dire la parola meravigliosa: “Interessante!". Al momento dell'apprendimento, si sonda ulteriormente e trovi il modo di rompere il software a cui i progettisti non hanno mai pensato, quindi fornire un rapporto che descrive in dettaglio numerosi assunzioni, guasti e rischi cattivi nel software. Scopri di più su questo nel libro chiamato Explore It.
Test di penetrazione
Nel mondo della sicurezza del software, i test di penetrazione sono uno dei mezzi principali di test. Tutti i sistemi, sia biologici, fisici o software, hanno confini e confini. Questi confini hanno lo scopo di consentire solo messaggi, persone o componenti specifici di inserire nel sistema. Più concretamente, consideriamo un sistema bancario online che utilizza l'autenticazione dell'utente per inserire il sito. Se il sito può essere hackerato ed inserito nel backend senza un'autenticazione adeguata, sarebbe una penetrazione, che deve essere protetta contro. L'obiettivo dei test di penetrazione è utilizzare tecniche note e sperimentali per bypassare il normale limite di sicurezza di un sistema software o di un sito Web. Il test di penetrazione spesso prevede il controllo di tutte le porte che stanno ascoltando e cercando di inserire un sistema tramite una porta aperta. Altre tecniche comuni includono l'iniezione SQL o la cracking della password.
Test di regressione
Dopo aver funzionato software distribuito sul campo, è fondamentale impedire l'introduzione di bug in funzionalità che stava già funzionando. Lo scopo dello sviluppo del software è aumentare la capacità del prodotto, introdurre bug o causare il funzionamento delle vecchie funzionalità, che è chiamata regressione. La regressione è un bug o un difetto introdotto quando in precedenza la capacità funzionava come previsto. Nulla può rovinare la reputazione del tuo software o del tuo marchio più velocemente dell'introduzione di bug di regressione nel tuo software e avere utenti reali trovare questi bug dopo una versione.
I casi di test di regressione e i piani di test dovrebbero essere costruiti attorno alla funzionalità di base che deve continuare a lavorare per garantire che gli utenti abbiano una buona esperienza con l'applicazione. Tutte le funzioni fondamentali del tuo software che gli utenti si aspettano di lavorare in un certo modo dovrebbero avere un caso di test di regressione che può essere eseguito per impedire alla funzionalità di interrompere una nuova versione. Questo potrebbe essere ovunque da 50 a 50.000 casi di test che coprono la funzionalità principale del software o dell'applicazione.
Test di bisection del codice sorgente
Un bug è stato introdotto nel software, ma non è ovvio quale versione della versione abbia introdotto il nuovo bug. Immagina che ci fossero 50 impegni software dall'ultimo tempo noto che il software funzionava senza il bug, fino ad ora quando ..
Test di localizzazione
Immagina un'applicazione meteorologica che mostra il tempo attuale e proiettato nella tua posizione, nonché una descrizione delle condizioni meteorologiche. La prima parte dei test di localizzazione è garantire che il linguaggio, l'alfabeto e i caratteri corretti siano visualizzati correttamente, a seconda della geolocalizzazione dell'utente. L'app nel Regno Unito dovrebbe essere visualizzata in inglese con personaggi latini; La stessa app in Cina dovrebbe essere visualizzata in caratteri cinesi in lingua cinese. Test di localizzazione più elaborati eseguiti, la gamma più ampia di persone di diverse geolocamenti si interfaccia con l'applicazione.
Test di accessibilità
Alcuni cittadini della nostra comunità hanno disabilità e, pertanto, potrebbero avere difficoltà a utilizzare il software, quindi i test di accessibilità vengono eseguiti per garantire che le popolazioni con disabilità possano ancora accedere alla funzionalità del sistema. Ad esempio, se supponiamo che l'1% della popolazione sia cieco a colori e la nostra interfaccia software presuppone che gli utenti possano distinguere tra rosso e verde, ma quegli individui ciechi non possono dire la differenza. Pertanto, un'interfaccia ben software avrà ulteriori spunti oltre il colore per indicare il significato. Altri scenari oltre ai test di cecità a colori sarebbero inclusi anche nei test di accessibilità del software, come la cecità visiva completa, la sordità e molti altri scenari. Un buon prodotto software dovrebbe essere accessibile in una percentuale massima di potenziali utenti.
Test di aggiornamento
App semplici su un telefono, sistemi operativi come Ubuntu, Windows o Mint Linux e software che esegue sottomarini nucleari necessitano di frequenti aggiornamenti. Il processo di aggiornamento stesso potrebbe introdurre bug e difetti che non esisterebbero su una nuova installazione perché lo stato dell'ambiente era diverso e il processo di introduzione del nuovo software in cima ai vecchi avrebbe potuto introdurre bug. Facciamo un semplice esempio, abbiamo un laptop che esegue Ubuntu 18.04 e vogliamo passare a Ubuntu 20.04. Questo è un diverso processo di installazione del sistema operativo rispetto alla pulizia diretta del disco rigido e all'installazione di Ubuntu 20.04. Pertanto, dopo l'installazione del software o una qualsiasi delle sue funzioni derivate, potrebbe non funzionare al 100% come previsto o come quando il software è stato installato di recente. Quindi, dovremmo prima considerare di testare l'aggiornamento stesso in molti casi e scenari diversi per garantire che l'aggiornamento funzioni al completamento. E poi, dobbiamo anche considerare di testare l'aggiornamento del sistema effettivo per garantire che il software sia stato stabilito e funzionante come previsto. Non ripeteremmo tutti i casi di test di un sistema appena installato, che sarebbe una perdita di tempo, ma penseremo attentamente con le nostre conoscenze sul sistema di ciò che potrebbe rompere durante un aggiornamento e aggiungere strategicamente casi di test per tali funzioni.
Black Box & White Box Test
Black Box e White Box sono metodologie di test meno specifiche e più tipi di test di categorizzazioni. In sostanza, il test Black Box, che presuppone che il tester non sappia nulla sul funzionamento interno del software e crea un piano di test e casi di test che guardano semplicemente il sistema dall'esterno per verificarne la funzione. Il test White Box viene eseguito da architetti software che comprendono i meccanismi interni di un sistema software e progettano i casi con conoscenza di ciò che potrebbe, dovrebbe, dovrebbe, ed è probabile che si rompa. È probabile che sia il test della scatola in bianco che nero troverà diversi tipi di difetti.
Blog e articoli sui test del software
Il test del software è un campo dinamico e molte pubblicazioni e articoli interessanti che aggiornano la comunità sul pensiero all'avanguardia ai test del software. Tutti possiamo beneficiare di questa conoscenza. Ecco un campione di articoli interessanti di diverse fonti di blog che potresti voler seguire:
- 7 suggerimenti da seguire prima del test senza requisiti; http: // www.testjournals.com/
- 60 migliori strumenti di test di automazione: la guida dell'elenco finale; https: // testguild.com/
- Strumenti di test del database open source; https: // www.softwaretestingmagazine.com/
- La copertura del test unitaria al 100 % non è sufficiente; https: // www.stickyminds.com/
- Test traballante su Google e come li mitighiamo; https: // test.Googleblog.com/
- Cos'è il test di regressione? ; https: // test.io/blog/
- 5 fasi di test software chiave che ogni ingegnere dovrebbe eseguire; https: // techbeacon.com/
Prodotti per il test del software
La maggior parte delle preziose attività di test può essere automatizzata, quindi non dovrebbe sorprendere che l'utilizzo di strumenti e prodotti per eseguire le miriadi di attività di garanzia della qualità del software sia una buona idea. Di seguito elencheremo alcuni strumenti software importanti e preziosi per i test software che puoi esplorare e vedere se possono aiutare.
Junit
Per il test del software basato su Java, Junit fornisce una suite di test completa per unità e test funzionali del codice amichevole per l'ambiente Java.
Selenio
Per il test delle applicazioni Web, Selenio fornisce la possibilità di automatizzare le interazioni con i browser Web, incluso il test di compatibilità del browser incrociato. Questa è un'infrastruttura di test principali per l'automazione dei test web.
Cetriolo
Un framework di test basato sul comportamento consente agli utenti aziendali, ai product manager e agli sviluppatori di spiegare la funzionalità prevista in linguaggio naturale e quindi di definire tale comportamento nei casi di test. Ciò rende casi di test più leggibili e una mappatura chiara alla funzionalità dell'utente prevista.
Purificare
Trova perdite di memoria e corruzioni di memoria in fase di esecuzione eseguendo il software con la strumentazione Purify Plus incorporata che tiene traccia dell'utilizzo della memoria e indica errori nel codice che non sono facili da trovare senza strumentazione.
VALGRIND
Strumenti open source che eseguiranno il tuo software e ti permetteranno di interagire con esso sottolineando un rapporto di errore di errori di codifica come perdite di memoria e corruzioni. Non è necessario ricompilare o aggiungere strumentazione nel processo di compilazione in quanto Valgrind ha l'intelligenza per comprendere dinamicamente il codice della macchina e iniettare la strumentazione perfettamente per trovare errori di codifica e aiutarti a migliorare il codice.
Copertura
Strumento di analisi statica che troverà errori di codifica nel tuo software prima ancora di compilare ed eseguire il codice. La copertura può trovare vulnerabilità di sicurezza, violazioni delle convenzioni di codifica, nonché bug e difetti che il tuo compilatore non troverà. Si può trovare il codice morto, variabili non inizializzate e migliaia di altri tipi di difetti. È fondamentale pulire il codice con un'analisi statica prima di rilasciarlo in produzione.
Jmeter
Un framework open source per i test delle prestazioni orientati agli sviluppatori basati su Java, da cui J nel nome. Il test del sito Web è uno dei principali casi d'uso per JMeter oltre al test delle prestazioni di database, sistemi di posta e molte altre applicazioni basate su server.
Metasploit
Per i test di sicurezza e penetrazione, Metasploit è un framework generico con migliaia di funzionalità e capacità. Usa la console di interazione per accedere agli exploit pre-codifica e prova a verificare la sicurezza dell'applicazione.
Ricerca accademica sui test del software
- Gruppo di ricerca sui test dell'Università di Sheffield
- Lab di verifica e validazione del software dell'Università del Kentucky
- Gruppo di ricerca di test software della North Dakota State University
- Test del sistema Lab intelligente; Praga dell'Università tecnica ceca
- NASA: Test e ricerche del software Jon McBride (JSTAR)
- McMaster University; Laboratorio di ricerca sulla qualità del software
- Ontario Tech University; Software Quality Research Lab
- L'Università del Texas @ Dallas; Stqa
Conclusione
Il ruolo del software nella società continua a crescere e, allo stesso tempo, il software del mondo diventa più complesso. Affinché il mondo funzioni, dobbiamo avere metodi e strategie per testare e convalidare il software che creiamo eseguendo le funzioni che ha lo scopo di eseguire. Per ogni sistema software complesso, una strategia di test e un piano di test dovrebbero essere in atto per continuare a convalidare la funzionalità del software mentre continuano a migliorare e fornire la sua funzione.