TEST MANUALE - TEST DEL SOFTWARE

Il test manuale è un processo di test del software in cui i casi di test vengono eseguiti manualmente senza utilizzare alcuno strumento automatizzato. Tutti i casi di test eseguiti manualmente dal tester secondo la prospettiva dell'utente finale. Garantisce se l'applicazione funziona, come menzionato nel documento dei requisiti, o meno. I casi di test vengono pianificati e implementati per completare quasi il 100% dell'applicazione software. Anche i report dei casi di test vengono generati manualmente.

Il test manuale è uno dei processi di test più fondamentali in quanto può individuare difetti sia visibili che nascosti del software. La differenza tra rendimento atteso e rendimento, dato dal software, è definita difetto. Lo sviluppatore ha corretto i difetti e lo ha consegnato al tester per riprovarlo.

Il test manuale è obbligatorio per ogni software appena sviluppato prima del test automatizzato. Questo test richiede grandi sforzi e tempo, ma dà la garanzia di un software privo di bug. Il test manuale richiede la conoscenza delle tecniche di test manuale ma non di alcuno strumento di test automatizzato.

Il test manuale è essenziale perché uno dei test del software fondamentali è 'l'automazione al 100% non è possibile'.

Perché abbiamo bisogno dei test manuali

Ogni volta che un'applicazione arriva sul mercato ed è instabile o presenta un bug o problemi o crea un problema durante l'utilizzo da parte degli utenti finali.

Se non vogliamo affrontare questo tipo di problemi, dobbiamo eseguire un ciclo di test per rendere l'applicazione stabile e priva di bug e fornire un prodotto di qualità al cliente, perché se l'applicazione è priva di bug, l'utente finale utilizzerà l'applicazione in modo più conveniente.

Se l'ingegnere di test esegue test manuali, può testare l'applicazione dal punto di vista dell'utente finale e acquisire maggiore familiarità con il prodotto, il che lo aiuta a scrivere i casi di test corretti dell'applicazione e a fornire un rapido feedback dell'applicazione.

Tipi di test manuali

Esistono vari metodi utilizzati per i test manuali. Ciascuna tecnica viene utilizzata secondo i propri criteri di prova. Di seguito sono riportati i tipi di test manuali:

Test della scatola bianca
Test della scatola nera
Test della scatola grigia

Test in scatola bianca

Il test della scatola bianca viene eseguito dallo sviluppatore, dove controlla ogni riga di un codice prima di consegnarlo al tecnico del test. Poiché il codice è visibile allo sviluppatore durante il test, ecco perché è noto anche come test White box.

Per ulteriori informazioni sul test della scatola bianca, fare riferimento al collegamento seguente:

https://www.javatpoint.com/white-box-testing

Test della scatola nera

Il test della scatola nera viene eseguito dal Test Engineer, dove può verificare la funzionalità di un'applicazione o del software in base alle esigenze del cliente/cliente. In questo caso il codice non è visibile durante l'esecuzione del test; ecco perché è noto come test della scatola nera.

Per ulteriori informazioni sui test black-box, fare riferimento al collegamento seguente:

https://www.javatpoint.com/black-box-testing

Test della scatola grigia

Il test della scatola grigia è una combinazione del test della scatola bianca e del test della scatola nera. Può essere eseguito da una persona che conosce sia la codifica che i test. E se la singola persona esegue il test della scatola bianca, così come quello della scatola nera per l'applicazione, è noto come test della scatola grigia.

Per ottenere maggiori dettagli sul test della scatola grigia, fare riferimento al collegamento seguente:

https://www.javatpoint.com/grey-box-testing

Come eseguire il test manuale

Innanzitutto, il tester osserva tutti i documenti relativi al software, per selezionare le aree di test.
Il tester analizza i documenti dei requisiti per coprire tutti i requisiti dichiarati dal cliente.
Il tester sviluppa i casi di test in base al documento dei requisiti.
Tutti i casi di test vengono eseguiti manualmente utilizzando il test Black box e il test white box.
Se si verificano bug, il team di test informa il team di sviluppo.
Il team di sviluppo corregge i bug e consegna il software al team di test per un nuovo test.

Processo di creazione del software

Una volta raccolto il requisito, verrà fornito ai due diversi team di sviluppo e test.
Dopo aver ottenuto il requisito, lo sviluppatore interessato inizierà a scrivere il codice.
E nel frattempo, l'ingegnere di test comprende i requisiti e prepara i documenti richiesti, fino ad ora lo sviluppatore può completare il codice e archiviarlo nel Strumento di controllo della versione .
Successivamente, il codice cambia nell'interfaccia utente e queste modifiche vengono gestite da un team separato, noto come costruire squadra .
Questo team di creazione prenderà il codice e inizierà a compilare e comprimere il codice con l'aiuto di uno strumento di creazione. Una volta ottenuto l'output, l'output va nel file zip, noto come Costruire (applicazione o software). Ogni build avrà un numero univoco come (B001, B002).
Quindi questa particolare build verrà installata nel server di test. Successivamente, l'ingegnere del test accederà a questo server di test con l'aiuto dell'URL di test e inizierà a testare l'applicazione.
Se l'ingegnere del test trova qualche bug, verrà segnalato allo sviluppatore interessato.
Quindi lo sviluppatore riprodurrà il bug nel server di test, risolverà il bug e memorizzerà nuovamente il codice nello strumento di versione di controllo, installerà il nuovo file aggiornato e rimuoverà il vecchio file; questo processo continua finché non otteniamo la build stabile.
Una volta ottenuta la build stabile, questa verrà consegnata al cliente.

Nota 1

Una volta raccolto il file dallo strumento di controllo della versione, utilizzeremo lo strumento di compilazione per compilare il codice dal linguaggio di alto livello al linguaggio di livello macchina. Dopo la compilazione, se la dimensione del file aumenta, comprimeremo quel particolare file e lo scaricheremo nel server di test.
Questo processo viene eseguito da Costruisci una squadra , sviluppatore (se il team di compilazione non è presente, può farlo uno sviluppatore) o il file cavo di prova (se il team di creazione gestisce direttamente il file zip e installa l'applicazione sul server di test e informa l'ingegnere del test).
Generalmente non possiamo ottenere una nuova build per ogni bug; altrimenti, la maggior parte del tempo verrà sprecata solo nella creazione delle build.

Nota 2

Costruisci una squadra

Il compito principale del team di compilazione è creare l'applicazione o la build e convertire il linguaggio di alto livello in linguaggio di basso livello.

Costruire

È un software utilizzato per convertire il codice nel formato dell'applicazione. E consiste in una serie di funzionalità e correzioni di bug che vengono consegnate al tecnico del test a scopo di test finché non diventa stabile.

Strumento di controllo della versione

È un software o un'applicazione utilizzata per il seguente scopo:

In questo strumento possiamo salvare diversi tipi di file.
È sempre protetto perché accediamo al file dagli strumenti utilizzando le stesse credenziali di accesso.
L'obiettivo principale degli strumenti è tenere traccia delle modifiche apportate ai file esistenti.

Esempio di processo di creazione

Vediamo un esempio per capire come costruire il lavoro del processo sugli scenari reali:

Non appena l'ingegnere del test rileva il bug, lo invierà agli sviluppatori e avranno bisogno di un po' di tempo per analizzarlo; dopodiché si limita a correggere il bug (il tecnico del test non può fornire la raccolta dei bug).

Lo sviluppatore decide quanti bug può correggere in base al tempo a sua disposizione. E l'ingegnere del test decide quale bug dovrebbe essere corretto per primo in base alle sue esigenze perché gli ingegneri del test non possono permettersi di interrompere i test.

E l'ingegnere di test che riceve la posta, può solo sapere quale bug è stato corretto dal elenco delle correzioni di bug .

Il tempo aumenterà perché alla prima Build gli sviluppatori dovranno scrivere il codice nelle diverse funzionalità. E alla fine, potrà solo correggere i bug e il numero di giorni verrà ridotto.

Nota 3

Ciclo di prova

Il ciclo di test è la durata di tempo concessa all'ingegnere di test per testare ogni build.

Differenze tra le due costruzioni

I bug riscontrati in una build possono essere risolti in qualsiasi build futura, a seconda dei requisiti dell'ingegnere del test. Ogni nuova build è la versione modificata di quella vecchia e queste modifiche potrebbero essere la correzione di bug o l'aggiunta di nuove funzionalità.

La frequenza con cui ricevevamo la nuova build

All'inizio ricevevamo build settimanali, ma nell'ultima fase di test, quando l'applicazione diventava stabile, ricevevamo la nuova build una volta ogni 3 giorni, due giorni o anche quotidianamente.

Quante build otteniamo

Se consideriamo un anno di durata del progetto, abbiamo ottenuto 22-26 build.

Quando avremo le correzioni dei bug

In genere, comprendiamo le correzioni dei bug solo dopo il completamento del ciclo di test o dopo che la raccolta di bug è stata corretta in una build e il passaggio nelle build successive.

Vantaggi del test manuale

Non richiede conoscenze di programmazione durante l'utilizzo del metodo Black box.
Viene utilizzato per testare progetti GUI che cambiano dinamicamente.
Il tester interagisce con il software come un utente reale in modo che sia in grado di scoprire problemi di usabilità e interfaccia utente.
Garantisce che il software sia privo di bug al cento per cento.
È conveniente.
Facile da imparare per i nuovi tester.

Svantaggi del test manuale

Richiede un gran numero di risorse umane.
Richiede molto tempo.
I tester sviluppano casi di test in base alle proprie competenze ed esperienze. Non ci sono prove che abbiano ricoperto tutte le funzioni o meno.
I casi di test non possono essere riutilizzati. Necessità di sviluppare casi di test separati per ogni nuovo software.
Non fornisce test su tutti gli aspetti del test.
Poiché due team lavorano insieme, a volte è difficile comprendere le motivazioni degli altri e ciò può fuorviare il processo.

Strumenti di test manuali

Nei test manuali, diversi tipi di test come unità, integrazione, sicurezza, prestazioni e tracciamento dei bug, abbiamo vari strumenti come Jira, Bugzilla, Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube, ecc. disponibili nel mercato. Alcuni strumenti sono open source e altri sono commerciali.

Per ulteriori informazioni sugli strumenti di test, fare riferimento al collegamento seguente:

https://www.javatpoint.com/software-testing-tools

Cerchiamo di capirli uno per uno:

CaricaRunner

È lo strumento di test delle prestazioni più comunemente utilizzato. LoadRunner viene utilizzato principalmente per supportare i test delle prestazioni per un'ampia gamma di procedure, numero di approcci e ambienti applicativi.

Lo scopo principale dell'esecuzione dello strumento LoadRunner è classificare rapidamente le fonti più comuni di problemi di prestazioni.

Caratteristiche di LoadRunner

Lo strumento LoadRunner contiene n numeri di applicazioni, il che riduce il tempo necessario per comprendere e descrivere i report.
Possiamo ottenere report approfonditi sui test delle prestazioni utilizzando lo strumento LoadRunner.
Ridurrà il costo dei test di carico distribuito e offrirà anche lo strumento operativo per il monitoraggio della distribuzione.

Agrumi

Citrus è uno strumento di test di integrazione, ovvero il framework di test più comunemente utilizzato. E' scritto dentro Programmazione Java lingua. Viene utilizzato principalmente per richiedere e rispondere lato server e lato client e convalidare i file XML JSON.

Per eseguire il test dei casi d'uso end-to-end, Citrus supporta diversi protocolli HTTP, JMS e SOAP.

Caratteristiche degli agrumi

Di seguito sono riportate alcune delle caratteristiche importanti dello strumento Citrus:

Viene utilizzato per inviare e ricevere messaggi.
Citrus è disponibile sia come open source che come licenza sul mercato.
Fornisce una soluzione a basso costo.
Possiamo autenticare il database utilizzando lo strumento agrumi.
Descriverà la sequenza dei messaggi, offrirà il piano di test e documenterà la copertura del test.
Crea il messaggio e verifica le risposte.

ZAP

ZAP è uno scanner di sicurezza per applicazioni Web open source. Sta per Proxy di attacco Zed . Proprio come alcuni altri strumenti, è anche scritto nel file Linguaggio di programmazione JAVA . È il più efficace Apri progetti di sicurezza delle applicazioni Web [OWASP].

Caratteristiche di ZAP

Supporta molti sistemi operativi come Windows, Linux, OS X.
Ha un'architettura basata su plugin.
Contiene un mercato online che ci consente di aggiungere funzionalità nuove o aggiornate.
Il pannello di controllo GUI di ZAP è facile da usare.

Suora

NUnit è uno degli strumenti di test unitario più utilizzati. È uno strumento open source e deriva principalmente da JUnit .

Era completamente scritto nel Linguaggio di programmazione C# e adatto a tutti Lingue della rete .

In altre parole, possiamo dire che lo strumento NUnit è stato interamente riprogettato per sfruttare molte qualità del linguaggio .Net. Per esempio:

Capacità legate alla riflessione. Altri attributi personalizzati. Test manuale

Caratteristiche di NUnit

Permette le asserzioni come metodo statico della classe di vantaggio.
Sostiene i test basati sui dati.
Supporta diverse piattaforme, come .NET core Xamarin mobile, Silverlight e un framework efficiente.
La capacità di NUnit ci aiuta a eseguire i test simultaneamente.
Utilizza un runner della console per caricare ed eseguire i test.

JIRA

Lo strumento di tracciamento dei bug utilizzato più regolarmente è JIRA , che è uno strumento open source. Viene utilizzato per il monitoraggio dei bug, la gestione dei progetti e il monitoraggio dei problemi.

In questo strumento possiamo facilmente tenere traccia di tutti i tipi di bug o difetti relativi al software e prodotti dagli ingegneri di test.

Caratteristiche di JIRA

È uno strumento che fa risparmiare tempo.
Jira viene utilizzato per tenere traccia dei difetti e dei problemi.
Viene utilizzato per stabilire le attività di documentazione.
Jira è uno strumento molto utile per monitorare il miglioramento della nostra documentazione.

Per ottenere informazioni complete sullo strumento Jira, fare riferimento al collegamento seguente: https://www.javatpoint.com/jira-tutorial.

SonarQube

Un altro strumento di test manuale è SonarQube, che migliora il nostro flusso di lavoro con qualità e sicurezza del codice continue. È flessibile con l'uso di plug-in.

È completamente scritto nel linguaggio di programmazione JAVA. Offre valutazione e integrazione completamente automatizzate con Ant, Maven, Gradle, MSBuild e strumenti di integrazione costante. SonarQube ha la capacità di registrare una cronologia delle metriche e fornisce il grafico dell'evoluzione.

Caratteristiche di Sonarqube

Di seguito sono riportate alcune delle caratteristiche significative dello strumento SonarQube:

Supporta diversi linguaggi di programmazione come C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL, ecc.
Sotto la GNU Lesser General Public License, Sonarqube è disponibile gratuitamente.
SonarQube è affiliato con alcuni importanti strumenti esterni come GitHub, Active Directory, LDAP e altri.
SonarQube si è fuso con gli ambienti di sviluppo Visual Studio, Eclipse e IntelliJ IDEA grazie a SonarLint plug-in.

JMeter

JMeter è uno strumento open source utilizzato per testare le prestazioni di risorse statiche e dinamiche e di applicazioni Web dinamiche.

È completamente progettato sull'applicazione JAVA per caricare il comportamento del test funzionale e misurare le prestazioni dell'applicazione.

Facilita agli utenti o agli sviluppatori l'utilizzo del codice sorgente per lo sviluppo di altre applicazioni.

Caratteristiche di JMeter

Di seguito sono riportate alcune delle caratteristiche essenziali di JMeter:

È indipendente dalla piattaforma e accetta un formato JVM simile Windows, Mac e Linux, ecc.
Supporta una GUI intuitiva, interattiva e semplice.
È incredibilmente estensibile per caricare il test delle prestazioni in più tipi di server.

Per ulteriori informazioni su JMeter, fare riferimento al collegamento seguente:

https://www.javatpoint.com/jmeter-tutorial.

Con Bugz

Un altro strumento di tracciamento dei bug utilizzato nei test manuali è Con Bugz .

È ampiamente utilizzato da molte organizzazioni per tenere traccia dei vari bug dell'applicazione.

Bugzilla è uno strumento open source che aiuta il cliente e il cliente a tenere traccia dei difetti. Bugzilla è anche considerato uno strumento di gestione dei test perché in questo possiamo facilmente collegare altri strumenti di gestione dei test case come ALM, Quality Center, ecc.

Caratteristiche di Bugzilla

Bugzilla ha alcune funzionalità aggiuntive che ci aiutano a segnalare facilmente il bug:

Supporta vari sistemi operativi come Windows, Linux e Mac.
Con l'aiuto di Bugzilla, possiamo elencare un bug in diversi formati.
Le preferenze dell'utente possono misurare la notifica e-mail.
Bugzilla ha funzionalità di ricerca avanzate.

Mantide

Mantis è un sistema di tracciamento dei bug basato sul web. ManitsBT sta per Localizzatore di insetti Mantis . Viene utilizzato per seguire i difetti del software ed eseguito nel linguaggio di programmazione PHP. È anche uno strumento open source.

Caratteristiche di Mantide

Alcune delle caratteristiche standard dello strumento particolare sono le seguenti:

Con l'aiuto di questo strumento, abbiamo l'accessibilità alla ricerca di testo completo.
Tracce di controllo delle modifiche apportate ai problemi.
Fornisce l'integrazione del sistema di controllo di revisione.
Controllo di revisione dei campi di testo e delle note

Per ottenere maggiori dettagli sugli strumenti di tracciamento dei bug, fare riferimento al seguente collegamento: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Un altro strumento di test di integrazione è Tessy , che viene utilizzato per eseguire l'integrazione e il test unitario per il software incorporato. Ci aiuta anche a scoprire la copertura del codice del software o di un'applicazione.

Può gestire facilmente l'intera organizzazione dei test, comprese le esigenze aziendali, la gestione dei test, la quantità di copertura e la tracciabilità.

Tessy contiene tre funzioni principali, che sono le seguenti:

Editor dell'interfaccia di test (TIE)
Editor dei dati di prova (TDE)
Spazio di lavoro.

Caratteristiche di TESSY

Le caratteristiche standard del TESSY sono le seguenti:

Produce il rapporto di prova per i risultati dell'esecuzione del test.
Supporta vari linguaggi di programmazione come C e C++.
Tessy viene utilizzato per valutare l'interfaccia della funzione e descrive la variabile utilizzata da quella funzione.

Per ulteriori informazioni sugli strumenti di test di integrazione, fare riferimento al seguente collegamento: https://www.javatpoint.com/integration-testing-tools.

Panoramica

In questo articolo abbiamo visto informazioni dettagliate su Test manuale, che include la definizione di test manuale, la necessità di test manuale, il tipo di test manuale, gli strumenti di test manuale, il processo di test manuale e alcuni importanti vantaggi e svantaggi dello stesso.

testo in grassetto css

Infine, possiamo dire che si tratta di un processo in cui l'ingegnere di test deve essere molto persistente, innovativo e reattivo.

Nei test manuali, l'ingegnere del test deve pensare ed eseguire l'interpretazione dell'utente finale.

Per implementare i test manuali, un ingegnere di test ha bisogno di abilità produttive e immaginazione. E devono pensare a più situazioni o scenari per testare un'applicazione specifica.

Anche se al momento possiamo testare quasi tutte le applicazioni con l'aiuto dei test automatizzati, sono comunque necessari i test manuali poiché costituiscono la base del test del software.