Qual è lo scopo del test del software? [chiuso]

8

Dopo aver letto molti libri, c'è una contraddizione di base:

Alcuni dicono che "l'obiettivo del testing è trovare i bug", mentre altri dicono "l'obiettivo del test è di equalizzare la qualità del prodotto", il che significa che i bug sono i suoi sottoprodotti.

Sarei anche d'accordo sul fatto che se il test fosse mirato principalmente a una caccia agli insetti, chi farebbe la verifica effettiva e fornirà effettivamente le informazioni che il software è pronto?

Anche ad es. Kaner ha cambiato la sua definizione originale di obiettivo di test dalla caccia agli insetti alla fornitura di valutazione della qualità, ma non riesco ancora a vedere la chiara differenza. Considero entrambi ugualmente importanti.

Posso verificare il software in base alle sue specifiche per assicurarmi che funzioni e in tal caso, i bug trovati sono solo per prodotti. Ma eseguo anche i test solo per rompere le cose.

Inoltre quale definizione è più accurata?

Nota sopra Mi riferisco principalmente al test del software come processo.

    
posta John V 05.10.2012 - 10:44
fonte

9 risposte

19

Come sono sicuro tu sappia, ci sono molti diversi tipi di test del software, come test di unità, test di integrazione, test di accettazione, ecc. Quindi è una specie di termine generico per tutti, e proprio a questo alto livello di discussione, possiamo solo parlare veramente di "qualità", come termine generale. Stai semplicemente convalidando il software contro qualsiasi misura di accettabilità che desideri applicare. A diversi livelli e tipi di test, questi varieranno notevolmente, e l'unico vero terreno comune è l'aspetto della qualità.

I bug (come tradizionalmente definiti) sono un tipo specifico di problema con il software, ma ce ne sono molti altri. A meno che non stiamo discutendo di un livello specifico e più basso di test, non ha senso limitare la definizione ai bug. Un'interfaccia utente è un po 'troppo lenta per un bug ? Che dire del fatto che ci siamo dimenticati di dire agli sviluppatori di aggiungere un cestino al nostro negozio web? Forse la confusione arriva con specifici tipi di test che vengono definiti "test del software", ma in realtà è solo semantica.

Se spinto a formalizzare la definizione, direi che il test è un processo di validazione del software rispetto alle tue esigenze (che può essere anche qualitativo). Un bug è solo una violazione molto specifica dei requisiti (in particolare, uno che lo sviluppatore pensava già funzionasse correttamente).

EDIT: dovrei probabilmente aggiungere che la parola "bug" ha significati molto diversi per persone diverse, e dovremmo effettivamente iniziare questa discussione semantica definendola. Sto usando la definizione dal punto di vista di uno sviluppatore - questo non funziona come io (lo sviluppatore) lo ha inteso. In genere si basa su un requisito molto specifico o un'interpretazione molto specifica di un requisito. La definizione del client è in genere simile - ciò non funziona come I (il client), ma è una cosa molto diversa. Usando la seconda definizione, potresti quasi eguagliare qualità e bug, perché tutto ciò che non soddisfa i desideri del cliente è un "bug".

    
risposta data 05.10.2012 - 11:04
fonte
10

Dalla risposta di Daniel B:

I'm using the definition from a developer's perspective - this doesn't work as I (the developer) intended it. It is typically based on either a very specific requirement, or a very specific interpretation of a requirement. The client's definition is typically similar - this doesn't work as I (the client) intended it, which is a very different thing indeed.

Questa è essenzialmente la differenza tra verifica e convalida. La verifica risponde alla domanda "L'abbiamo costruita correttamente?" La convalida risponde alla domanda "Abbiamo costruito la cosa giusta?" Test di verifica e test di validazione sono cose piuttosto diverse. La verifica è un compito molto più semplice della convalida. Con la verifica, sai cosa testare: i requisiti (o le storie) che spiegano cosa dovrebbe fare il software. C'è un problema qui: cosa succede se quei requisiti o storie sono sbagliati? Come testate quel problema? Questo è ciò che la convalida tenta di risolvere.

Ancora un altro componente utilizzato in alcuni ambienti è il concetto di accreditamento. Questo diventa importante quando il software viene riutilizzato. Esempio: supponiamo di costruire una simulazione di un veicolo e di aver bisogno di un buon modello della sua unità di misura inerziale. È possibile trovare un modello IMU esistente nella libreria del modello dei componenti. Questo modello esistente è stato accuratamente verificato rispetto ai requisiti e convalidato contro la realtà. Il test è molto esteso, compresi i confronti con i dati di volo. Verificato e convalidato! Suona bene! Basta riutilizzarlo così com'è.

Poi di nuovo, forse no. L'uso previsto di quel modello potrebbe essere stato operazioni quiescenti, il tuo uso è quello di modellare un razzo durante la fase di lancio. Il comportamento dell'IMU durante il lancio sarà vicino al comportamento delle specifiche: in altre parole, pessimo. Le IMU in genere hanno prestazioni molto migliori rispetto alle specifiche durante le operazioni di quiescenza. L'uso previsto di quel modello non corrisponde al tuo uso previsto. Faresti meglio a non riutilizzarlo. I tentativi di accreditamento vanno oltre la verifica e la convalida. Risponde alla domanda "È questa la cosa giusta per questo specifico uso previsto?"

Un altro esempio è il primo test di volo del razzo Ariane 5. Il bug del software che ha portato al fallimento del volo 501 è considerato uno dei più infami e costosi bug del software di tutti i tempi. Il software di volo è estremamente costoso da costruire. Per evitare questi enormi costi, il software di volo Ariane 5 ha riutilizzato grossi pezzi del software di volo Ariane 4. Ampiamente verificato e convalidato e già utilizzato in un contesto reale. Quindi riutilizzalo così com'è. Sbagliato. Dovrebbe essere stato accreditato per il riutilizzo. Si è verificato un evento "impossibile accadere" che ha comportato un overflow di conversione da 64 bit a 16 bit e il veicolo non è riuscito.

    
risposta data 05.10.2012 - 13:45
fonte
5

What is the aim of software testing?

In breve: come commentano gli autori di domande "in generale, il test del software come processo". - La tua domanda è ampia, ed ecco la sua definizione in articolo di Wikipedia .

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation.

Pertanto, il obiettivo del test del software è fornire informazioni indipendenti sulla qualità del prodotto / software. - Come deve essere fatto e sottoprocesso di test del software? - è una domanda diversa da cercare.

Modifica: il processo di test del software deve essere fornito in modo indipendente in base ai requisiti aziendali. Altrimenti, ci sarebbe meno valore in esso. In effetti, i progetti software di grandi dimensioni (come i progetti immobiliari nazionali o simili) hanno un margine separato per il controllo di qualità, i test e i processi di verifica / accettazione del software.

    
risposta data 05.10.2012 - 12:52
fonte
4

Identifica regressioni del software non appena si presentano.

Il test unitario, in particolare, ha lo scopo di identificare regressioni precoce nella costruzione / testing / distribuzione della catena

Il test di accettazione è più sulla linea di completamento del contratto con un cliente . Ma poi di nuovo, se una parte di un test di accettazione non passa mentre era invece previsto, hai identificato una regressione da gestire.

    
risposta data 05.10.2012 - 16:16
fonte
2

Credo che il libro "The Art of Software Testing" di Glenford J. Myers lo definisca meglio:

"Testing is the process of executing a program with the intent of finding errors."

Contrasta questa definizione con diverse definizioni comuni:

  • "Testing is the process of demonstrating that errors are not present."
  • "The purpose of testing is to show that a program performs its intended functions correctly."
  • "Testing is the process of establishing confidence that a program does what it is suppose to do."

Piuttosto che provare a dimostrare che un programma funziona, dovremmo pensare che il programma abbia degli errori, e l'obiettivo dei test del software è di trovarli. In tal modo, viene aumentata la qualità del software, che è l'obiettivo finale del test del software.

    
risposta data 05.11.2012 - 11:15
fonte
1

@David La risposta di Hammen è molto buona, anche se non esattamente quello che avrei detto. Sono d'accordo che la verifica risponde "L'abbiamo costruita correttamente?". Qualsiasi cosa prodotta da un processo può essere verificata. La produzione implica la costante verifica che la cosa prodotta sia stata prodotta correttamente.

Quindi definisce Validation, che siamo d'accordo è diverso, come "Abbiamo costruito la cosa giusta?" Direi che Validation si muove nella direzione opposta, per confermare in modo esaustivo il corretto funzionamento di un design. Più come "Dimostrare obiettivamente che la soluzione è stata progettata correttamente". I giusti gradi di bulloni, le giuste dimensioni delle variabili interne. I pezzi sono all'altezza del lavoro.

David's Validate, "Abbiamo costruito la cosa giusta?" è una domanda di alto livello che non è qualcosa che puoi eseguire contro la build giornaliera, i pollici in su o i pollici in giù. È un giudizio sui requisiti e, in misura minore, sul design. Non è una domanda sensata indirizzata a una casella di testo su uno schermo o un parametro in un'API. Non sei sicuro di quale sia il nome di una sola parola per la correttezza dei requisiti, magari Validazione dei requisiti. Dimostrando in modo esauriente che i requisiti corrispondono alle esigenze dell'utente finale.

Al contrario, la mia definizione di Validate è la prova della correttezza di un progetto, test oggettivi che mostrano che i pezzi selezionati faranno il lavoro. Il software Ariane IV che era inadatto per Ariane V fallirebbe qui, perché Ariane IV aveva una gamma limitata di cambi angolari. Il codice è stato ottimizzato per questa gamma limitata, e Ariane V era in grado di avere una gamma più ampia di tassi d'angolo, che ha causato l'overflow. Quando entrambi i computer di bordo si sono bloccati in overflow e lo hanno fatto di nuovo dopo il riavvio automatico, il sistema di distruzione è stato attivato.

Come diceva Dykstra, "L'ottimizzazione prematura è la radice di tutto il male."

Nelle mie definizioni, si presume che i requisiti siano corretti e accettati, convalidati dalla verifica dei requisiti. La progettazione o la convalida del codice dimostra che il design, forse un po 'di implementazione, è corretto. Deve comunque essere eseguito correttamente, ma conferma che è Verification, testing basato su Requisiti accettati e Design accettato.

Noterai che questo si avvicina dolorosamente al modello di sviluppo Waterfall, che sembra dannoso se si ritiene che descriva sistemi complessi. Tuttavia, i requisiti sono diversi rispetto a Design e Code è una terza cosa interamente. Credo che il mio motivo sia che gli elementi della cascata sono descrizioni utili, ma che "completo" è fuorviante, quindi l'ho modificato in "accettato" che suggerisce contingenza e mutabilità.

    
risposta data 07.02.2014 - 03:37
fonte
0

Il test del software non ha lo scopo di trovare bug, ma ha lo scopo di prevenire i bug. Un corretto test nelle fasi iniziali impedisce ai bug di introdurlo nei sistemi di produzione.

    
risposta data 05.10.2012 - 12:25
fonte
-1

Penso che gli investimenti nei test siano destinati a "migliorare l'esperienza dell'utente".

Molte volte vengono lasciati errori perché non influenzano negativamente l'utilizzo del prodotto. Allo stesso modo, "l'equalizzazione della qualità del prodotto" sarà anche suddivisa in base a quanto è utile lavorare su una determinata area. Infine, i criteri "abbastanza buono da spedire" devono essere riconosciuti in quanto lo stato finale per i test è sempre soggettivo.

    
risposta data 07.10.2012 - 04:01
fonte
-1

Un software con una grande qualità è, tra le altre cose, un software con 0 (o pochissimi) bug. Quindi una caccia al bug è un processo per migliorare la qualità.

Un software che soddisfa tutte le sue caratteristiche è anche un ottimo software di qualità, quindi testare per convalidare le funzionalità è un processo per migliorare la qualità.

Un software che una buona esperienza utente è un ottimo software di qualità, e così via ...

Bene, penso che l'obiettivo dei test di sotware sia di migliorare la qualità, quindi è possibile eseguire alcuni test di bug, alcune convalida e verifica delle funzionalità, alcuni test sull'interfaccia utente, ecc.

    
risposta data 09.01.2013 - 10:24
fonte

Leggi altre domande sui tag