Come pianificare per test strutturale

Question

Sono relativamente nuovo per il mondo del WhiteBox test e hanno bisogno di aiuto progettazione di un piano di test per 1 dei progetti che sto attualmente lavorando. Al momento sto solo scouting in giro alla ricerca di pezzi testabili di codice e poi scrivendo alcuni test di unità per questo. In qualche modo sento che è di gran lunga non è il modo in cui dovrebbe essere fatto. Si prega potreste darmi consigli su come meglio prepararmi per testare questo progetto? Strumenti o modelli di piano di test che potrei usare? Il linguaggio utilizzato è il C ++ se farà differenza.

Answer 1

Uno degli obiettivi di test white-box è quello di coprire il 100% (o il più vicino possibile) delle istruzioni di codice. Io suggerisco di trovare uno strumento di copertura di codice C ++ in modo da poter vedere ciò che il codice i test eseguire e quale codice che avete perso. Quindi progettare le prove in modo che quanto più codice possibile è testato.

Un altro suggerimento è quello di esaminare le condizioni al contorno in se statments, cicli for, while etc. e prova per eventuali zone 'grigie', i falsi positivi e falsi negativi.

Si potrebbe anche progettare le prove a guardare il ciclo di vita delle variabili importanti. Metti alla prova la loro definizione, il loro utilizzo e la loro distruzione per assicurarsi che essi sono utilizzati correttamente:)

Ci sono tre idee per iniziare. Buona fortuna

Answer 2

  

Al momento sto solo scouting in giro alla ricerca di pezzi testabili di codice e poi scrivendo alcuni test di unità per questo. In qualche modo sento che è di gran lunga non il modo in cui dovrebbe essere fatto.

La gente dice che uno dei principali vantaggi di ' Test Driven Development ' è che ti ecourages per progettare i componenti con testabilità in mente: rende i componenti più verificabili

.

---

Il mio approccio (non-TDD) personale è la seguente:

• Comprendere la funzionalità richiesta e implementato: sia 'a priori' (vale a dire con la lettura / conoscendo il software specifica funzionale), e leggendo il codice sorgente di decodificare la funzionalità
• Implementare test scatola nera per tutte le funzionalità implementate / richieste (si veda ad esempio ' Se uno prova implementazione interna, o testare solo comportamento pubblico? ').

Il mio test, pertanto, non è del tutto 'scatola bianca', se non che decodificare la funzionalità in fase di test. Sono quindi verificare che la funzionalità decodificato, ed evitare qualsiasi codice inutile (e quindi non testato). Potrei (ma spesso non) utilizzare uno strumento di copertura di codice per vedere come gran parte del codice sorgente è esercitato dal test scatola nera.

Answer 3

Prova "Lavorare in modo efficace con il codice legacy": http: //www.amazon. com / lavoro-efficace-Legacy-michael-Feathers / dp / 0131177052

E 'rilevante, in quanto da 'legacy' egli intende il codice che non ha le prove. E 'anche un buon libro piuttosto.

strumenti rilevanti sono: http://code.google.com/p/googletest/ e http://code.google.com/p/gmock/ Ci possono essere altri framework di unit test e finti, ma ho la familiarità con questi e li consiglio vivamente.