Sono uno studente che lavora sul mio BE (CS) e la mia domanda è la seguente:

1. Sono necessari test nel campo del software?
2. Se creiamo un software con grande cura, perché dovremmo testarlo?
3. Dopo i test possiamo essere sicuri di aver raggiunto questo obiettivo (il prodotto / software funziona come previsto) perché abbiamo fatto i test per questo? È possibile?

La mia domanda: è necessario testare il software ?

Sì. Perché non importa quanto tu sia bravo, non puoi pensare a tutto.

• Ti verrà anche chiesto di fare in modo che il tuo software esegua operazioni che non hai mai previsto.
• Non avrai mai requisiti così chiari da poter pensare a tutte le possibilità per assicurarti che il codice non si rompa.
• Lavorerai anche con software e API di altre persone che non funzioneranno sempre come previsto, ma assumerai che ciò comporti, o dovrebbe, portare a difetti nel tuo caso "perfetto".

sì

Per lo stesso motivo per cui uno chef assaggia il suo cibo mentre lo cucina.

Lavoro con qualcuno che la pensa in questo modo, pensa che, essendo un programmatore senior, non ha più bisogno di testare il suo codice. La compagnia non capisce quanto sia pericoloso questo atteggiamento e invece di licenziarlo completamente hanno assunto più programmatori per affrontare l'arretrato di bug. Non sapendo da dove provenga questo arretrato pensano che sia parte di ciò che la programmazione riguarda. Fondamentalmente abbiamo 3 programmatori che lavorano in questa modalità e un team di 20 che non fa altro che testare e correggere i bug che questi tre creano.

ASSENZA DI GIUSTE PROVE DI UCCISIONE .

Quindi, a meno che tu non sia DIO o qualunque versione di qualche essere perfetto (ora questo mi piacerebbe vedere) o se non vuoi essere licenziato molto velocemente, ti consiglio vivamente di iniziare i test.

Il software è scritto da persone.

Le persone sono imperfette e commettono errori.

Man mano che aumenta la complessità di un'impresa, aumenta il numero potenziale (e l'impatto) di errori, sviste o cose dimenticate - di solito in modo esponenziale.

Quindi sì, sono necessari dei test. Porta equilibrio e prospettiva.

Salirai su un volo che esegue un sistema operativo che sai di aver usato sul tuo laptop e ti ha dato uno schermo di morte nel tuo colore preferito? Pensaci.

Nessun programmatore è perfetto. Lontano, molto, molto lontano. Hai bisogno di test e spesso i tester mettono in prospettiva (anche noti come casi d'uso) che mancavano agli sviluppatori.

Fai una ricerca sui più famosi bug del software su Google per sapere cosa intendo.

E a livello universitario, leggi alcune informazioni sullo sviluppo basato su test, test unitari e pratiche agili per sapere dove sono le cose in questo momento.

Il test è un must assoluto per qualsiasi applicazione non banale (per dimensioni o funzione) che deve essere effettivamente utilizzata. Non troverai un singolo sviluppatore che si preoccupa del proprio mestiere (come evidenziato dalla loro visita a questo sito) che risponderà e dirà che il test non è necessario.

Oltre a ciò che è già stato pubblicato, avere una suite completa di test di unità automatizzati su una determinata applicazione ti renderà più sicuro delle future modifiche al codice. Questa maggiore confidenza (poiché i test unitari forniscono una GRANDE rete di sicurezza) comporterà modifiche più rapide del codice alle applicazioni esistenti (a causa di meno backtracking / doppio controllo)

Errare humanum est

Non esiste un software privo di bug.

Lo sviluppatore più esperto scrive codice con bug. Anche se esistesse uno sviluppatore perfetto, ci sarebbero ancora bug a causa di discrepanze tra:

• esigenze dell'utente e documenti di specifica
• specifiche e design
• ambienti hardware e software previsti ed effettivi
• verità di ieri e di oggi: tutto quanto sopra elencato è soggetto a cambiamenti che non sono perfettamente riportati in ogni fase del processo di sviluppo.

Lo sviluppatore perfetto è solo una parte del tutto. E non esistono sviluppatori perfetti.

La maggior parte dei programmi di vita reale:

a) contenere centinaia di righe di codice o più, distribuite su numerosi file;
b) sono sviluppati da più di un programmatore;
c) utilizzato in ambienti diversi dall'ambiente dello sviluppatore

Pertanto, se non si controlla come funziona il programma nella vita reale, la probabilità che non funzioni affatto sarebbe vicina al 100%.

Oltre a tutte le altre grandi risposte, anche se conosci il suo perfetto e privo di bug, pensa agli altri programmatori che dovranno gestire il tuo codice in futuro. Non lo sapranno come te e vorranno fare affidamento sui test per assicurarsi di non aver rotto nulla dopo aver apportato una modifica. Questo ovviamente vale anche per te stesso dopo che non vedi il tuo codice da un anno!

SÌ.

Ecco un'altra prospettiva leggermente più sottile che non è ancora stata del tutto coperta:

Non sottovalutare mai la necessità di "verifica indipendente" . È lo stesso motivo per cui è bene che alcuni editor indipendenti esaminino il tuo lavoro prima di inviare un grosso pezzo di scrittura per la pubblicazione. Non importa quanto tu sia bravo come scrittore, di tanto in tanto fai il brainfart e scrivi qualcosa come "in" al posto di "it", o qualcosa del genere. Se lo rileggi da solo, anche con molta attenzione, di solito ti mancherà, perché il tuo cervello accetta automaticamente il flusso del tuo processo di pensiero come corretto e sorvola l'errore. Per una nuova serie di occhi, questo tipo di errore è di solito abbastanza evidente.

Ottieni la stessa cosa nella programmazione: è abbastanza facile entrare in un flusso in cui il tuo codice o il tuo "test di sviluppo" di base del tuo codice - sembra corretto perché lo stai testando e lo stai usando in un certo modo. Ma poi quando arriva un altro paio di mani e fa clic sulle cose in un modo o in un ordine leggermente diverso, tutto si blocca.

Ora, naturalmente, si potrebbe , in teoria, imboccare la strada di verificare formalmente ogni singola possibilità e la logica filiale nel codice te stesso, ma per il software non banale questo sarà molto più costoso e richiede molto tempo di avere qualcun altro botto sul codice per te. E probabilmente ti mancheranno ancora cose a cui non hai mai pensato.

Ciò che non è stato ancora toccato: anche se il tuo codice è perfetto, non sei ancora al sicuro. I compilatori hanno bug che possono causare un comportamento errato anche del codice perfetto dopo la compilazione. I sistemi operativi presentano bug che possono causare un comportamento binario perfetto in modo errato durante l'esecuzione. L'hardware ha dei bug che possono causare problemi.

Questo è anche il motivo per cui i test su una macchina non sono sufficienti per i prodotti commerciali. Devono essere testati con quante più combinazioni possibili di hardware e software possano incontrare in natura quanto è fattibile.

Il leader del team che ha scritto il software per la navetta spaziale è volato via prima di ogni lancio per indicare che il software non avrebbe danneggiato la navetta.

Cosa pensi che gli abbia dato la fiducia necessaria per farlo?

Stai costantemente testando il codice semplicemente compilandolo e utilizzandolo. In alcuni IDE si ottengono controlli di integrità durante la digitazione. A meno che tu non esegua realmente il tuo codice, stai facendo dei test.

Quanto testate è davvero la radice di questo tipo di domanda e la risposta a ciò scende a rischio. Test tanto quanto ha senso testare dal punto di vista della gestione del rischio. Testare tutto o niente è generalmente impossibile. Testare quasi nulla è di solito una mossa sbagliata. Tutto nel mezzo è un gioco equo a seconda del livello di rischio e dell'esposizione del risultato finale.

Odora di una domanda a casa.

Sono necessari test nel campo del software?

Sì. Assolutamente. A tutti i livelli. Al di fuori di alcuni domini specializzati, non siamo ancora in una fase in cui possiamo dimostrare matematicamente che il nostro codice è corretto contro bug specifici (almeno non in un lasso di tempo ragionevole), quindi dobbiamo lanciarci contro per vedere se e dove si rompe.

Se creiamo un software con grande cura, perché dovremmo testarlo?

Il test non riguarda solo la ricerca di errori di codifica. Si tratta anche di assicurarsi di aver soddisfatto tutti i requisiti e che l'intero sistema funzioni come previsto. Se ho la necessità che una transazione fallita debba restituire un codice di errore specifico, allora devo scrivere un test per verificare sia l' esistenza della funzionalità sia il corretto funzionamento.

E tutto ciò presuppone che le specifiche e il design siano completi, corretti e coerenti internamente, il che spesso non è il caso. Anche se soddisfi le specifiche alla lettera e segui il disegno fino all'ultimo punto e punto e virgola, se la specifica o il disegno sono sbagliati, ci saranno problemi al momento dell'integrazione. Spesso, i test di sistema o di integrazione si verificano quando si scopre che le specifiche stesse sono errate e devono essere riviste (vedere la storia di guerra di seguito).

Dopo i test possiamo essere sicuri di aver raggiunto questo obiettivo (il prodotto / software funziona come previsto) perché abbiamo fatto i test per questo? È possibile?

No, non al 100%. Non possiamo testare ogni possibile combinazione di input o percorsi di esecuzione in nessun altro che nel codice più semplice. Non possiamo tenere conto di tutti i fattori ambientali. Non possiamo immaginare tutte le possibili modalità di fallimento.

Possiamo testare al punto in cui siamo ragionevolmente sicuri che non ci siano grossi problemi. Ancora una volta, è per questo che dobbiamo testare a tutti i livelli. Scrivi una serie di test per assicurarti che il codice gestisca correttamente le condizioni dei bordi (input errato, risultati imprevisti, eccezioni, ecc.). Unit test per verificare che il codice soddisfi i suoi requisiti. Test di sistema per verificare l'elaborazione end-to-end. Test di integrazione per verificare che tutti i componenti si parlino correttamente. Esegui test di usabilità per assicurarti che tutto funzioni in modo tale che i clienti non vogliano spararti.

Scenario del mondo reale: stavo lavorando su un sistema di back-end che occasionalmente inviava aggiornamenti a un servizio GUI per la visualizzazione in una tabella sullo schermo. Durante il progetto, è stato aggiunto un requisito per aggiungere filtri al display (ad esempio, l'operatore può scegliere di visualizzare un sottoinsieme delle voci nella tabella). Errore di progettazione n. 1: il filtro avrebbe dovuto essere filtrato dal servizio della GUI (ho questa idea antica e antiquata secondo cui le funzioni di gestione dello schermo dovrebbero essere responsabilità del software di gestione dello schermo), ma a causa della politica e della mia incapacità di riconoscere i problemi prima che diventino problemi , tale requisito è stato posto sul servizio back-end. Bene, ok, nessun problema, posso farlo. Lo stato del filtro cambia, ricevo un messaggio e quindi invio un messaggio di creazione o eliminazione perogni riga nella tabella , perché è così che funziona l'interfaccia (errore di progettazione n. 2: non è possibile inviare aggiornamenti a più righe in un singolo messaggio; non è nemmeno possibile inviare un singolo messaggio "cancella" o "elimina" per cancellare l'intero tavolo).

Bene, tutto funziona bene durante lo sviluppo; test di unità, sistema e integrazione dimostrano che invio le informazioni giuste e gestisco correttamente le modifiche al filtro. Quindi arriviamo ai test di usabilità e tutto cade a fatica , perché il volume di dati è stato travolgente. La latenza di rete tra il mio servizio di back-end e la GUI è stata dell'ordine da .15 a .25 secondi. Non male se devi solo inviare aggiornamenti per una dozzina di righe o giù di lì. Mortale quando devi inviare aggiornamenti per diverse centinaia. Abbiamo iniziato a ricevere segnalazioni di bug secondo cui la GUI si stava bloccando dopo aver modificato lo stato del filtro; beh, no, quello che stava succedendo era che stava prendendo nell'ordine di diversi minuti per aggiornare il display perché il protocollo di aggiornamento testa a fila una volta alla volta non poteva gestire uno scenario del mondo reale.

Si noti che tutto questo potrebbe avere e dovrebbe sono stati anticipati da tutti, dal prime contractor tutta la strada fino al piccolo vecchio me se avessimo preso la briga di fare anche l'analisi più semplice in anticipo. L'unica difesa che offrirò è che stavamo chiudendo il secondo anno di un progetto di sei mesi che sarebbe stato spazzato via quasi immediatamente dopo la consegna, ed eravamo tutti disperati nel vedere il retro di esso.

Il che ci porta all'ultimo motivo per testare - CYA. I progetti del mondo reale falliscono per una serie di motivi, molti dei quali politici, e non tutti agiscono in buona fede quando le cose vanno male. Le dita vengono puntate, le accuse vengono fatte e alla fine della giornata devi essere in grado di indicare un record che mostra che almeno le tue cose hanno funzionato come previsto.

I test verranno sempre eseguiti e verranno sempre trovati dei bug. È solo che il tuo team eseguirà i test internamente o l'utente finale sarà il tester. Il costo di un bug rilevato dall'utente finale è tremendamente superiore rispetto a quando fosse stato rilevato durante il test.

Suggerirei di seguire un buon corso di informatica tollerante agli errori. Un'attenta progettazione del software è solo uno dei pilastri per raggiungere la robustezza del prodotto software. Gli altri due pilastri sono test sufficienti e design ridondante. L'intento di base è di accogliere un numero esponenziale di condizioni di errore sconosciute e di stabilire le priorità nel trattare con alcune di quelle conosciute:

1.) eliminare il maggior numero possibile di guasti attraverso la progettazione e l'implementazione corretta 2.) eliminare gli errori imprevisti dalla fase di progettazione e l'implementazione errata attraverso varie forme di test (unità, integrazione, casuale) 3.) affrontare eventuali guasti rimasti attraverso la ridondanza ( temporale => ricalcola, riprova o spaziale => conserva copie, parità)

Se si elimina la fase di test, si lasciano solo fasi di progettazione e ridondanza per la risoluzione degli errori.

Inoltre, dal punto di vista del prodotto, i vostri stakeholder (ad es. Gestione, utenti, investitori) vorranno una sorta di rassicurazione che il vostro prodotto soddisfi determinate specifiche di qualità e sicurezza, criteri, ecc. A parte tutto ciò, non avete testato il software che hai costruito solo per avere un "controllo di integrità"? Tutti questi motivi rendono i test del software più convincenti.

Tutti i programmi hanno dei bug, almeno per cominciare.

Ci sono stati alcuni studi che convergono su circa 1 bug ogni cinque righe di codice non testato.

Una lezione di storia:

Negli anni '60 IBM aveva bisogno di un programma "NOP" per poter eseguire alcune funzionalità in JCL senza eseguire effettivamente un programma. Gli sviluppatori hanno ideato un programma di assemblaggio a una riga in cui l'intero codice era contenuto nel suo nome "IEFBR14", il codice effettivo era:

       BR 14 * brach to return address in register 14

Durante il suo lungo periodo di tempo, questo programma a una riga è stato oggetto di 2 segnalazioni di errori e cinque modifiche.

Il refactoring del codice è molto più veloce quando si hanno test unitari. Un test unitario mostra anche l'uso semplice della funzione concreta, quindi hai un piccolo "howto" che può essere davvero utile in grandi progetti in cui i programmatori non conoscono esattamente l'intero codice.

Quando si sta sviluppando con TDD (sviluppo guidato dai test) non si hanno getter / setter non necessari, ecc. È sufficiente creare ciò di cui si ha bisogno.

Per rispondere alla terza domanda:

Essendo stato programmatore e tester del software, sì, puoi essere sicuro di soddisfare i requisiti del software durante i test.

{indossare il cappello QA}

Come? È possibile farlo tracciando i test dal codice del test ai criteri di accettazione, dai criteri di accettazione alle caratteristiche e dalle caratteristiche ai requisiti. Se si traccia ogni singolo test nella catena di progettazione e si associano a uno o più requisiti, si può essere certi che i test vengano utilizzati per garantire che il codice soddisfi i requisiti (anche se questo porta alla nozione di adeguata copertura del test, che è un un altro argomento). Se non riesci a rintracciare un test nella catena di progettazione, probabilmente stai testando le cose che non sono necessarie e questa è una perdita di tempo. I criteri di accettazione possono anche includere la verifica di comportamenti indesiderati: è possibile testare anche quelli, il che ti avvicina di un passo alla qualità.

{Cappello QA disattivato}

Nessun codice è mai privo di bug, solo meno costoso nel tempo quando si impiegano maggiori sforzi per valutarne la qualità durante lo sviluppo.

Sono stato un tester del software per 3 anni ormai. Inizialmente io stesso ero scettico sulla necessità di testare, dal momento che pensavo che se il dipartimento di sviluppo e la gestione dei progetti facessero il loro lavoro, non dovrebbero sorgere errori nel software.

MA non è così. ++++++++

Gli errori si verificano spesso, alcuni dei quali fondamentali per il funzionamento di un progetto. Esistono anche test cross-browser (il che significa test su diversi browser esistenti come SAFARI, FIREFOX, CHROME e Internet Explorer) e ho lavorato al progetto in cui semplici pulsanti di interfaccia come YES e NO su una finestra del sondaggio dove non funzionavano solo in tutti i browser alcuni di quelli.

Ho lavorato sui test delle pagine Internet e stavo testando semplici CAMBIAMENTI DI TESTO e ho pensato a me stesso che in nessun modo sulla Terra ci sarebbero stati difetti in questo semplice lavoro, ma non succede.

Inoltre ho visto quando i nuovi sviluppatori si uniscono al team e ricevono un pezzo di lavoro di aggiornamento in un modulo di applicazione Internet complesso esistente con una serie di collegamenti / chiamate a pagine esterne, si è verificato un errore a causa della mancanza di comunicazione tra vecchi e nuovi sviluppatori, per vari motivi (nessun tempo per educare, nessuna volontà di educare e così via).

SÌ

Immagina che il tuo software sia solo una funzione logica AND (b1, b2) in cui b1 e b2 sono solo bit. Per questo sono necessari 4 casi di test per essere sicuri che il software sia privo di errori, se l'ambiente circostante fornisce esattamente ciò per cui sono stati specificati.

Ora il tuo sistema è composto da molte funzioni la cui più semplice è molto più complicata di quella funzione logica. Come ti assicureresti che sia privo di errori?

(continua)