Test della casella bianca e tabelle di traccia

3

Ho visto tabelle di traccia elencate sotto test white-box in una parte del mio programma, e separatamente sotto test a secco in un'altra parte. Qualcuno potrebbe chiarire se le tabelle di traccia sono generalmente considerate come parte di uno o entrambi i tipi di test?

L'ho studiato approfonditamente e non ho trovato nulla che risolva questa ambiguità. Ad esempio in: link

e

link

Le tabelle di traccia sono elencate come una tecnica a secco.

Il syllabus ( link ) contiene un'ambiguità che desidero ricevere aiuto con il chiarimento per i miei studenti.

    
posta Robin 26.05.2018 - 08:53
fonte

2 risposte

4

Una tabella di traccia non è altro che un log linea per linea che include numeri di riga del codice sorgente e contenuto di variabili. Questa è ovviamente una tecnica white-box , poiché è strongmente accoppiata agli interni di implementazione di ciascun metodo sotto test. È una tecnica di test (e debugging) molto vecchia, suppongo che abbia 40 anni, intesa per codice procedurale, e i tuoi link lo menzionano ancora come una tecnica spesso fatta usando carta e penna. Oggi le persone utilizzano tipicamente un debugger e passano il codice riga per riga o istruzione per riga, usando le funzionalità di tracciamento e monitoraggio del debugger.

Il termine dry-run non è definito in modo preciso, ma nel contesto dei tuoi link, probabilmente significa eliminare un pezzo di codice da un programma più grande ed eseguirlo con un input gestibile dati. "Eseguendo" si usa anche un foglio di carta, ma IMHO non fa necessariamente parte della definizione del termine "a secco". Questa è anche una terminologia e un approccio molto vecchi, con un'età simile alla prima. L'equivalente moderno è unit test , che rende le operazioni a secco indolori, ripetibili ed efficaci, senza bisogno di carta e penna.

Ora, i test unitari possono essere usati insieme al passaggio del codice usando un debugger, questa è una tecnica efficace per capire cosa fa il codice, specialmente quando si cerca un errore. Spesso è più efficace dell'uso del debugger nel contesto di un programma complesso. Tuttavia, i test unitari sono anche (e in realtà più spesso) usati senza un debugger, questi usi sono ortogonali.

Questo vale ancora di più per provare a utilizzare una tabella di traccia su carta: nel contesto di una sezione di codice ampia e complessa, questo diventa rapidamente ingestibile. Quindi è meglio usarlo nel contesto di uno scenario a secco.

Quindi in breve

  • l'utilizzo di una tabella di tracciamento (o di debug passo dopo passo) è sempre una tecnica di test white-box

  • una tabella di traccia è più efficace in uno scenario a secco (o in un test di unità), ma questa non è una connessione obbligatoria e non fa parte della sua definizione

Come ultima osservazione: un programma che menziona i test a secco, ma non i test unitari come tecnica di test di base, sarebbe probabilmente migliorato da un aggiornamento.

    
risposta data 26.05.2018 - 11:12
fonte
0

Donald Firesmith, della SEI, ha avuto un grande saggio sulla Tassonomia di test e le tabelle di traccia non sono elencate (l'elenco è esaustivo, ma potrebbe non essere aggiornato). Ottieni le diapositive qui complete (sono indispensabili per qualsiasi sviluppatore SW ).

Considero le tabelle di traccia come prove di prova e sono applicabili a più tipi di test, non solo a whitebox. Quindi, le tabelle di traccia non sono un tipo di test, ma un artefatto di test.

Potresti anche entrare in contatto con Donald Firesmith e ottenere il suo parere.

    
risposta data 26.05.2018 - 16:03
fonte

Leggi altre domande sui tag