Q & A sulla qualità SE # 1

Question:Scrivi una breve nota sul processo di test del software.

Answer:- Il test del software può essere definito come un processo il cui obiettivo è trovare il problema nell'implementazione di un programma. L'esecuzione di questo programma è molto necessaria per il progetto software. Secondo i mezzi di test IEEE,

il processo di esercizio o valutazione di un sistema o di suoi componenti con mezzi manuali o automatizzati per

  • Audit sulle necessità necessarie completato dal test del software.

  • Ottieni il valore della differenza tra il risultato proposto e il risultato effettivo.

Per rendere il semplice processo di test del software è necessario che le attività siano suddivise in piccole dimensioni. Generalmente viene utilizzato questo metodo e il sistema è suddiviso in sottosistemi. Tutti quei sottosistemi sono stati testati individualmente prima dell'inizio del processo di test del sistema. Durante il processo di test del software vengono eseguiti tre passaggi. Il modulo individuale è la parte principale del focus durante la fase di test unitario. Dopo il test unitario, tutti i singoli moduli vengono combinati tra loro. Dopo questo passaggio, inizia il processo di test del software e lo sviluppatore si concentra sul sistema software completo.

Test di unità

Questa è la prima fase del processo di test del software e su questa fase il programmatore conferma la funzione svolta dal modulo. Il software ha l'unità più piccola che si chiama modulo. Dopo lo sviluppo del codice sorgente, inizia il test unitario e verifica la corretta sintassi. L'obiettivo principale del test unitario è quello di ottenere l'unità minima che sarà in grado di assaggiare e confermare che funziona o meno. Ogni singolo modulo testato separatamente. Dopo aver testato tutti i singoli moduli vengono combinati tra loro. Alcuni test vengono eseguiti nell'ambito del processo di test unitario che è:

  • Nature test of module - Nel test di natura modulo verifichiamo che il flusso di informazioni è positivo nel modulo testato in quella situazione che è specificata per lo unit test.

  • Performable test - Questo punto di controllo ha l'obiettivo di calcolare il periodo di tempo di risposta, l'ora di inizio, l'ultima volta e durante l'intero processo il tempo e la comunicazione tra i collegamenti.

  • Local data structure test - La memorizzazione dei dati locali viene controllata in questo passaggio che tutti i dati e le informazioni vengano raccolti in modo sistematico o meno.

  • Boundary test - Questo test viene eseguito per la certezza che le informazioni fornite dal software sono vere o meno alle condizioni fornite dagli utenti.

  • Independent path test- In questo test viene verificato che l'attività data sia eseguita correttamente o meno e funzioni correttamente. Solo con l'aiuto di questo test puoi verificarlo.

  • Error handling test- L'errore che si è verificato durante il processo è gestito correttamente o meno. Questo tipo di informazioni fornite in questo test.

Processo di unit test

Nel processo di unit test sono necessari i dati o le informazioni richieste su altri moduli. Con l'aiuto di driver e stub possiamo facilmente ottenere. Un programmatore che dà il test e lo passa dove il modulo testato è chiamato driver. I programmi utilizzati per sostituire il modulo e i subordinati del modulo in fase di test sono chiamati stub. Stub e driver sono la necessità del processo di unit test. La quantità di stub e unità può essere ridotta se hanno la qualità della semplicità.

Test di integrazione

Il test di integrazione è il passaggio successivo del test del software. In questo test molti tipi di moduli che vengono testati individualmente vengono combinati tra loro in un sottosistema che viene quindi testato. L'obiettivo principale del test unitario è quello di ottenere informazioni sulla condizione di funzionamento del modulo indipendente è positivo, ma l'inconveniente principale del test unitario non ha tale condizione che dà la garanzia che questi moduli forniscono il risultato positivo dopo il collegamento come un intero sistema. Quindi questo è il motivo per eseguire il test di integrazione. Dobbiamo controllare i seguenti errori che possono influenzare l'integrazione del modulo.

  • I dati esterni possono creare il problema.

  • Il test fuori modulo potrebbe essere lontano dalle aspettative.

  • È possibile che il risultato dell'integrazione non sia a favore di quel processo o modulo.

Generalmente il test di integrazione utilizza due metodi.

Test di integrazione top down

Questo tipo di metodo ha una vasta area di pensiero. È necessario un modulo di alto livello dopo il test e prima integrato. In base a questo approccio, il modulo è stato sostituito e fornito di nuovi stub. Questo processo continua a quel livello fino a quando non integra tutti i moduli e viene testato. In questo approccio logica di alto livello e flusso di dati utilizzati che riducono la necessità dei conducenti.

Benefici

  • In primo luogo i moduli di livello superiore testati.

  • Entrambi approccio "ampiezza e profondità" supportati.

  • È richiesto un conducente al massimo.

Disegna indietro

  • I moduli di basso livello richiedono molto tempo per la verifica.

  • Dati non corretti si trovano nello stub per feedback a favore del modulo di chiamata.

  • Il livello di supporto è basso per la funzionalità limitata.

  • Complica la gestione dei test richiesta per lo stub.

Test di integrazione dal basso verso l'alto

Questo approccio dà importanza ai moduli di livello inferiore. In questo livello i moduli vengono prima testati e con l'aiuto di un driver integrato prima. Possiamo aggiungere uno o più moduli abbinati o uniti tra loro. Dopo l'integrazione di tutti i moduli, questo processo è stato chiuso.

Benefici

  • Quando iniziamo questo processo con il modulo effettivo, gli stub non sono necessari.

  • Modulo di basso livello verificato all'inizio di questo approccio.

Disegna indietro

  • Complica la gestione dei test richiesta per i conducenti.

  • Rilascio di funzionalità limitate supportate da basso livello.

  • Verifica del tempo impiegato dal modulo di alto livello.

Test di sistema

Il processo di test del sistema è la base di un sistema software. L'obiettivo principale del test del sistema è che il software soddisfi i requisiti del cliente. Il test del sistema è una serie di quell'intero test con esercizio completo la cui base è il sistema informatico. Ogni attività ha un obiettivo separato e una serie di test diversi è chiaro che tutte le parti del sistema sono combinate in modo sistematico e fanno il loro lavoro molto bene. Esistono tre tipi di test nei test di sistema.

  1. Recovery Testing- La base del test progettato in Recovery è di quel tipo che possiamo facilmente osservare quanto velocemente un sistema copre i suoi punti se il sistema si guasta. Abbiamo molti tipi di programmi che si riprendono rapidamente dagli errori e vengono avviati in un determinato momento o utilizzati in un determinato momento. Un guasto ha molte cause, ma i test di ripristino hanno chiarito che il sistema ha coperto tutti i guasti e ha funzionato bene. Un umano ha sempre desiderato che un sistema avesse la capacità di recuperare molto velocemente senza il contatto umano. Il sistema di ripristino ha stabilito che la condizione di riparazione è accettabile o meno.

  2. Security testing

    • Un'applicazione protettiva realizzata in software, con l'aiuto di questa applicazione fornisce sicurezza dal locale e da coloro che non hanno il diritto di utilizzare il sistema.

    • Con l'aiuto del test di sicurezza, un altro computer non può ottenere il vantaggio di accedere a questo e alle sue informazioni.

  3. Stress testing- Lo stress test non può essere eseguito in condizioni normali. Con l'aiuto di questo un sistema utilizza in quella condizione quando la domanda è aumentata o diminuita rapidamente.

    • Come si comportava una funzione di input quando la velocità di input diventava superiore alle aspettative.

    • Anche la ricerca e la caccia più eccessive dei dati sui clic sono coinvolte negli stress test.