Testing Software: Specification vs Structural

Podcast

Play an AI-generated podcast conversation about this lesson

Questions and Answers

Quale delle seguenti caratteristiche descrive meglio il testing 'specification-based'?

Richiede una conoscenza approfondita della struttura dei dati e delle funzioni del software.

Considera il sistema come una 'scatola nera', dove l'implementazione interna è irrilevante. (correct)

Si basa sull'analisi dettagliata dell'implementazione del codice.

Utilizza metriche di code coverage per valutare l'efficacia dei test.

Qual è uno svantaggio principale del metodo di testing 'specification-based'?

I test devono essere modificati ogni volta che l'implementazione del software cambia.

Potrebbe trascurare alcune parti del software, lasciandole non testate. (correct)

Non è adatto per i sistemi complessi con molteplici percorsi di possibile esecuzione.

È difficile sviluppare i casi di test parallelamente allo sviluppo del software.

Come viene caratterizzato il testing 'structural-based'?

È indipendente dall'implementazione del codice.

Si basa sulle specifiche funzionali del software.

Utilizza la code coverage come metrica per valutare la completezza dei test. (correct)

Considera il software una 'scatola nera', senza esaminare il codice.

Quale tra le seguenti affermazioni è un vantaggio fondamentale del testing 'specification-based' rispetto al 'structural-based'?

Non richiede modifiche ai test se l'implementazione del software viene cambiata. (B) Signup and view all the answers

In che modo il 'structural/code-based testing (white-box)' si differenzia dal 'specification-based testing (black-box)'?

Il testing 'white-box' si concentra sull'implementazione del codice, mentre quello 'black-box' si concentra sugli input e output del sistema. (C) Signup and view all the answers

Quale formula calcola la percentuale di copertura in base al numero di rami e condizioni coperti?

$rac{numero\ di\ rami\ coperti + numero\ di\ condizioni\ coperti}{numero\ di\ rami + numero\ di\ condizioni} \times 100%$ (D) Signup and view all the answers

Quanti test sono necessari per ottenere una path coverage completa con 4 condizioni binarie?

16 (A) Signup and view all the answers

Qual è lo scopo principale del criterio MC/DC (Modified Condition/Decision Coverage)?

Ridurre il numero di test rispetto alla path coverage, concentrandosi sulle combinazioni più significative. (B) Signup and view all the answers

Quanti test sono necessari per ottenere una copertura MC/DC completa con una decisione che contiene 5 condizioni?

6 (B) Signup and view all the answers

Quale affermazione confronta correttamente i criteri di Path coverage e MC/DC (Modified Condition/Decision Coverage)?

Path Coverage richiede $2^n$ test con 'n' condizioni, mentre MC/DC ne richiede n+1, risultando in meno test. (D) Signup and view all the answers

Qual è lo scopo principale dello structural testing?

Completare il testing dello specification-based testing, assicurandosi che tutto il codice venga eseguito. (A) Signup and view all the answers

Quale criterio di code coverage richiede che ogni riga di codice venga eseguita almeno una volta?

Line Coverage (B) Signup and view all the answers

Cosa si intende per 'branch coverage'?

Il test di ogni possibile percorso di esecuzione di un blocco condizionale (sia vero che falso). (B) Signup and view all the answers

Se una condizione complessa `if (!Character.isLetter(str.charAt(i)) && (last == 's' || last == 'r'))` è testata usando il criterio di 'Condition + Branch Coverage', quanti casi di test sono necessari?

6 (A) Signup and view all the answers

Qual è il primo passo nello structural testing dopo aver completato il testing basato sulle specifiche?

Leggere l'implementazione per capire le decisioni nel codice. (A) Signup and view all the answers

Se si ha un codice con 100 linee e 80 sono coperte dai test, qual è la Line Coverage?

80% (C) Signup and view all the answers

Cosa si intende con il termine 'Variazioni particolari' nel contesto del testing, secondo il contenuto proposto?

Testare input come stringhe contenenti spazi, che potrebbero non essere stati presi in considerazione inizialmente. (D) Signup and view all the answers

Qual è l'ultimo passo del processo di structural testing?

Eseguire nuovamente la test suite per verificare che tutte le nuove modifiche siano coperte (C) Signup and view all the answers

Qual è l'obiettivo principale dello stubbing nel testing software?

Sostituire le dipendenze reali con versioni semplificate per controllare i risultati. (B) Signup and view all the answers

In quale scenario è più appropriato l'uso di un mock rispetto a uno stub?

Quando si vuole verificare il numero di chiamate a un metodo e i parametri passati. (C) Signup and view all the answers

Quale scenario NON è adatto all'utilizzo di mocks?

Metodi che appartengono a librerie standard come <code>ArrayList</code>. (A) Signup and view all the answers

Qual è il vantaggio principale dello stubbing in termini di infrastruttura di test?

Semplifica il testing, evitando la necessità di infrastrutture complicate come database. (D) Signup and view all the answers

Cosa si intende per 'isolamento' nel contesto dello stubbing?

La classe testata non dipende dal comportamento o stato di altre componenti. (A) Signup and view all the answers

Come si configura un mock per lanciare un'eccezione?

Usando <code>doThrow(new Exception()).when(mock).method();</code> (D) Signup and view all the answers

Quale tra le seguenti affermazioni descrive meglio la differenza tra mocks e stubs?

Gli stubs sono utilizzati per restituire valori predefiniti; i mocks registrano interazioni e permettono verifiche dettagliate. (C) Signup and view all the answers

Qual è il termine corretto per indicare una versione semplificata di una dipendenza reale, utilizzata nel testing?

Stub (A) Signup and view all the answers

Qual è lo scopo principale della lista dei problemi generata durante un'ispezione del codice?

Aggiornare la checklist dei problemi per future ispezioni. (B) Signup and view all the answers

Quale tra le seguenti NON è una categoria tipica di problemi in una checklist di ispezione del codice?

Problemi di compatibilità hardware. (D) Signup and view all the answers

Cosa accade se un produttore assume una posizione difensiva durante un'ispezione del codice?

Il processo di ispezione diventa inefficace. (A) Signup and view all the answers

Perché i feedback delle ispezioni del codice dovrebbero essere confidenziali?

Per non indurre a presupporre che un programmatore sia incompetente. (D) Signup and view all the answers

Qual è uno dei principali benefici aggiuntivi dell'ispezione del codice, oltre al rilevamento degli errori?

Fornire feedback prezioso per lo stile di programmazione del produttore. (B) Signup and view all the answers

Cosa si intende con 'problemi di design' in una checklist di ispezione del codice?

Incoerenze o violazioni nei principi di progettazione. (C) Signup and view all the answers

Quale azione intraprende di solito il moderatore se la lista di problemi esistenti necessita di correzioni sostanziali?

Pianifica un'altra riunione di ispezione. (B) Signup and view all the answers

Qual è lo scopo principale della checklist dei problemi utilizzata nelle ispezioni del codice?

Sistematizzare la ricerca dei difetti e migliorare l'efficacia delle ispezioni. (D) Signup and view all the answers

Quale delle seguenti è una caratteristica dei metodi 'pseudo-testati'?

Sono metodi che passano tutti i test anche se la loro implementazione viene sostituita con <code>return null</code>. (A) Signup and view all the answers

Qual è il ruolo principale di un'infrastruttura per i test di integrazione e di sistema?

Configurare, pulire l'ambiente, recuperare e verificare dati complessi e automatizzare operazioni generiche per i test. (B) Signup and view all the answers

Quale scopo hanno strumenti DSL come Robot Framework e Cucumber nella scrittura dei test?

Permettere a stakeholder non tecnici di scrivere test grazie a un linguaggio quasi naturale. (D) Signup and view all the answers

Qual è la prima fase del Test-Driven Development (TDD)?

Scrivere un test che fallisce inizialmente. (C) Signup and view all the answers

In quale fase del TDD si scrive il codice di produzione?

Dopo che un test fallisce. (D) Signup and view all the answers

Qual è lo scopo della fase di 'rifattorizzazione' nel TDD?

Migliorare la struttura e la leggibilità del codice senza cambiarne il comportamento esterno. (C) Signup and view all the answers

Secondo l'esempio fornito, cosa dovrebbe restituire la funzione quando riceve la stringa 'XIV'?

14 (C) Signup and view all the answers

Qual è il vantaggio di utilizzare sia test unitari sia test di integrazione?

Serve per individuare meglio sia i problemi a livello di singolo componente, che le interazioni tra i componenti. (A) Signup and view all the answers

Study Notes

Introduzione alla Dispensa ITSS

La dispensa è un riassunto sull'integrazione e sui test dei sistemi software.
L'autore è Tarulli Marrafia Alessia.

1 Software Testing

Cos'è il Software Testing? È un insieme di attività per pianificare, preparare e valutare i prodotti software per verificare se soddisfano i requisiti, se sono mirati allo scopo desiderato e per trovare difetti nel codice.
Errori, Bug e Failure: Gli errori umani possono creare bug (difetti nel codice), che a loro volta possono causare failure (fallimenti) quando il codice è in esecuzione. Un sintomo di failure è un incident.
Test e Test Case: Il testing è l'esecuzione del software attraverso casi di test, con l'obiettivo di individuare bug o malfunzionamenti e dimostrare la corretta esecuzione del prodotto. Un test case specifica un insieme di input e i corrispondenti output attesi per un determinato comportamento.

1.3 Test Case

Elementi essenziali di un Test Case: Un test case deve includere un identificatore, una descrizione dello scopo, le precondizioni, gli input, gli output attesi, e le postcondizioni, oltre allo storico dell'esecuzione.

1.4 Identificare i casi di test

Dominio di input: Le possibili combinazioni di input per un sistema.
Strategie per individuare casi di test:
- Test funzionali (specification-based): basati sulle specifiche del prodotto. Sono "black-box", in quanto la struttura interna del prodotto è ignota ai test.
- Test strutturali (code-based): studiano la struttura interna del codice. Sono anche detti "white-box".

1.4.1 Specification-based Testing

Vantaggi: I test sono indipendenti dall'implementazione e possono essere sviluppati parallelamente a questa.
Svantaggi: Non vengono testati tutti i possibili percorsi del codice.

1.4.2 Structural-based Testing (Code-Based)

Approccio basato direttamente sull'implementazione del codice sorgente.
White-box testing: Permette di testare tutti o quasi tutti i percorsi di esecuzione del programma.

1.5 Errori e Difetti

Processo: Come un sistema crea qualcosa.
Prodotto: Il risultato di un processo.
Software Quality Assurance: Migliora i processi per ridurre gli errori e migliorare i prodotti (software).
Testing: Si concentra in particolare sull'individuazione dei difetti in un prodotto (software).

1.6 Livelli di Testing (V-model)

I livelli di testing riflettono i livelli di astrazione del modello a cascata.
I livelli di testing comprendono: sistematico, d'integrazione e unit testing.

2 Specification-based Testing

Requisiti: Descrivono cosa un software deve fare (quali sono gli ingressi e quali sono le uscite desiderate). Sono la base dell'approccio specification-based dei test.

2.2 Workflows per il Testing basato su Specifiche

Comprendere i requisiti e gli output: Identificare cosa deve fare il programma e quali sono le uscite per ogni input.
Input, output, e partizioni: Definire i possibili ingressi, output e partizioni di questi.
Casi limite: Identificare i casi limite (valori estremi e situazioni speciali).
Test Cases: Ideare dei casi di test.
Automatizzazione: Automatizzare i casi di test, utilizzando uno strumento come JUnit

2.2.1 Comprendere i requisiti, gli input e le uscite

Ognuno dei tre punti di suddivisione dei requisiti è fondamentale.

2.2.2 Esplorazione degli input possibili

Una tecnica per aumentare la comprensione funzionale del programma.

2.2.3 Esplorare input e output, identificare le partizioni

Scopo: individuare subset di input/output che forniscono completa certezza sulla correttezza funzionale del programma.

3 Testing strutturale e copertura del codice

Passaggi per il testing strutturale:
1. Applicare i passaggi di testing basati su specifiche.
2. Studiare l'implementazione, cercando di capire come il codice gestisce le decisioni.
3. Utilizzare uno strumento di copertura del codice per identificare le parti di codice non coperte dai test.
4. Definire perché un pezzo di codice non è stato coperto.
5. Creare un testcase per coprire il pezzo di codice mancante.
6. Tornare al punto 3
Criteri di copertura del codice:
- Line coverage: Quanti righe di codice sono state eseguite.
- Branch coverage: Quanti rami (condizioni) di codice sono stati eseguiti.
- Condition/Decision coverage: Qualsiasi condizione logica (es. una condizione if) in cui sia il ramo vero (true) che quello falso (false) sono stati testati.
- Path coverage: Tutti i percorsi possibili di esecuzione del programma sono coperti dai test.

3.3 Condizioni complesse e il criterio di copertura MC/DC

Cosa fa: Identifica le combinazioni di condizioni che sono necessarie per coprire il codice al meglio.
Vantaggio: Rende più complete le suite di test.

3.4 Gestire cicli e strutture simili

Lo scopo è definire come i test devono coprire tutti gli stati di un ciclo e gestire i diversi percorsi di esecuzione.

4 Progettare contratti

Design by contract: Metodologia per definire requisiti e comportamenti attesi in classi e metodi.
- Precondizioni: Requisiti preliminari per il corretto funzionamento.
- Postcondizioni: Risultati garantiti dopo l'esecuzione.
- Invarianti: Condizioni che devono essere vere durante l'intero ciclo di vita dell'oggetto.

4.1 Perché progettare i contratti

Ogni classe o metodo sappia cosa aspettarsi (pre-condizioni).
Ogni metodo restituisca risultati corretti (post-condizioni).
Lo stato interno degli oggetti rimanga consistente (invarianti).

4.2 Elementi fondamentali

Pre-condizioni: Requisiti che devono essere soddisfatti prima dell'esecuzione.
Post-condizioni: Condizioni che devono essere soddisfatte dopo l'esecuzione.
Invarianti: Condizioni che devono essere mantenute validi durante tutto il ciclo di vita dell'oggetto.

4.3 Esempi pratici

TaxCalculator: Calcolo tasse, pre-condizione valore maggiore di zero, post-condizione risultato non negativo.
Basket: Rappresenta il carrello della spesa, con metodi per aggiungere e rimuovere prodotti, pre-condizioni e post-condizioni relative.

4.4 Assert e Controllo delle Condizioni

Asserts sono test automatici, che, in caso di condizione non rispettata, interrompono l'esecuzione.

5 Test basati su proprietà

Definizione: Verifica che un sistema soddisfi le caratteristiche generali previste, anziché i singoli casi d'uso.
Vantaggi:
- Copertura più ampia: copre un gran numero di casi d'uso o partizioni.
- Riduzione della dipendenza da esempi: Il framework automatizza la generazione dei casi di test casualmente.

5.1 Differenza tra Example-Based e Property-Based Testing

Example-Based Testing (EBT): Approccio tradizionale. I casi di test sono creati manualmente, basati sull'esperienza e sulla specificità del progetto.
Property-Based Testing (PBT): Approccio moderno. Genera in automatico molti esempi di input per testare le proprietà del programma in esame.

5.3 Processo di PBT

Definire le proprietà: Si identificano le proprietà generali del programma.
Generazione degli input: Si genera un gran numero di input per testare le proprietà individuate.
Esecuzione dei test: Il programma viene eseguito con gli input generati. Per ogni input, se una proprietà viene violata, il test fallisce.

6 Test Double e Mocks

Generalità: Oggetti (o componenti) utilizzati per simulare il comportamento di componenti o dipendenze reali in un test, per isolare e rendere più veloci i test.
Dummy Objects: Oggetti di riempimento, utilizzati per soddisfare i requisiti di parametri di metodi, senza alcuna implementazione.
Fake Objects: Simulazione di oggetti reali, ma con implementazioni semplificate o alternative, spesso in modo che il framework di test non debba accedere a database esterni.
Stubs: Restituiscono valori predefiniti o in base a criteri interni, con funzionalità più semplici di quelle reali.
Mocks: Registrano chiamate e controlli, per valutare il comportamento effettivo del codice da testare in risposta ad un determinato input.

6.1 Tipi di Test Doubles

Si descrivono i diversi tipi di test double, i casi in cui sono impiegati, i vantaggi e gli svantaggi di ogni implementazione

6.2 Framework Mocking (Mockito)

Si descrive il framework Mockito, il cui scopo è facilitare la creazione e la gestione di mocks.

6.3 Stubbing delle Dipendenze

Descrivere cosa è lo stubbing e perché è utile per il testing.

6.5 Best Practices per l'uso dei Test Double

Si forniscono le best practices per l'uso dei test double, per ottimizzare le strategie adottate per il testing.

7 Testing Statico

Definizione: Un approccio per individuare anomalie nel codice software senza eseguire il codice effettivamente.
Si descrivono diverse tecniche di questo tipo di testing.

7.1 Analisi Statica

Descrizione, utilizzo degli strumenti, e i difetti che può rilevare

7.2 Tipi di revisione del codice

Ispezione del codice (Code Inspection): Revisione formale condotta da un gruppo di esperti per identificare difetti.
Revisione del codice (Code Walkthrough): Presentazione informale di chi ha scritto il codice, per raccogliere feedback.
Verifica a scrivania (Desk Checking): il programmatore rivede il codice da solo per individuare possibili errori.
Valutazione tra pari (Peer Review): Valutazione del codice, del lavoro o della competenza di uno sviluppatore da parte dei suoi colleghi basata su criteri di qualità, efficienza e conformità agli standard.

7.3 Revisione del Codice: Ispezione e Walkthrough

Si descrivono i passaggi per le revisioni del codice, ispezione e walkthrough.

7.4 Code Inspection

Si descrive il metodo di code inspection e descrive le persone coinvolte.

7.5 Desk Checking

Un tipo di revisione del codice, eseguito da una persona diversa da chi ha scritto il codice.

7.6 Peer Rating

Valutazione che si concentra sulla qualità complessiva del programma (manutenibilità, estensibilità, usabilità).

7.7 Auditing

Un esame indipendente per valutare la conformità a standard.

7.8 Pair Programming

Descrizione dei ruoli, le motivazioni, i vantaggi, e il ruolo nel metodo XP.

7.9 GitHub Copilot

Rappresenta un'implementazione di "pair programming" con intelligenza artificiale.

8 Progettazione per Testabilità

Separazione del codice: Separare il codice di dominio dal codice di infrastruttura.
Controllabilità e osservabilità.
Modifica del codice di produzione: A volte il test si complica se i test non sono progettati bene, quindi bisogna modificare il codice di produzione per facilitare il testing.

8.3 Controllabilità e Osservabilità

Controllabilità: Facilità con cui iniettare valori arbitrari nel codice testato.
Osservabilità: Facilità con cui visualizzare i risultati o l'output.

8.4 Principio di Inversione delle Dipendenze

Moduli di alto livello non dovrebbero dipendere dai moduli di basso livello. Entrambe le parti dovrebbero dipendere da astrazioni o interfacce.
Vantaggi: Riduce la dipendenza da dettagli, migliorando la testata.

8.5 Coesione

Coesione: Un modulo, una classe o un metodo dovrebbe avere una sola responsabilità.
Problema: Classi non coese hanno test più ampi.
Soluzione: Rifattorizzazione delle classi.

8.6 Conclusione

Separazione del codice: Separare il codice di infrastruttura dal codice di dominio.
Controllabilità e osservabilità: Rendi il codice controllabile e osservabile.
Modifica al codice di produzione (se necessario): A volte bisogna modificare il codice di produzione per rendere il testing più facile.

9 Test di Integrazione & Sistema

Definizione: Esercita gruppi di componenti correlati e l'interazione con servizi esterni (es. Database).
Test di Sistema: Verifica l'intero sistema end-to-end, simulando l'interazione dell'utente.
Test d'integrazione: I Test d'integrazione verificano l'interazione tra componenti di un sistema per testare il processo d'integrazione tra gli applicativi.
Tecniche di testing SQL: Gestione di query SQL che non selezionano alcuna riga, query che selezionano righe identiche, query con sottoquery, gestione di predicati LIKE, date e stringhe.
Verifica dei vincoli del database: Utilizzare JUnit per la verifica dei vincoli del database.
Implementazione JDBC di InvoiceDao: Si mostra un esempio, come creare una classe base per gestire le connessioni al database.
Best Practices per i Test di Integrazione: Si forniscono le best practices: creare una classe base, ridurre i dati, considerare evolzione dello schema.

10 Test di Sistema

Introduzione ai test di sistema.
Esempio applicativo web.
Flusso di lavoro applicativo web.
Strumenti (Selenium).
Test dei percorsi utente.
Page Objects (POs).
Esempio di test di sistema.

11 TDD (Test-Driven Development)

È una metodologia di sviluppo software dove si scrivono i test prima dell'implementazione del codice.
Vantaggi: Controllare il ritmo, feedback veloci, codice testabile, facile da modificare, migliore capacità di riflessione sui requisiti.
Casi limite, stringhe vuote e nulle.
Passaggi del TDD:
1. Scrivere un test che fallirà.
2. Implementare il codice che fa passare il test.
3. Rifattorizzare il codice per migliori pratiche, sicurezza e eleganza.

12 Integrazione Tra Sistemi Software

Motivazioni per l'integrazione di sistemi software (es. evoluzione sistemi, tecnologie obsolete).
Tecniche e strumenti EAI (Enterprise Application Integration).

Studying That Suits You

Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

Description

Questo quiz esplora le differenze tra il testing basato su specifiche e quello basato su strutture. Viene analizzato il significato, i vantaggi, e le critiche di ciascun metodo. Testa la tua conoscenza su criteri come MC/DC e Path Coverage.