M3U1:Test Documentazione by Emanuele Bertolero

Uso di convenzioni per i nomi delle funzioni e delle variabili

matteo_susca — 2019-01-27 16:10:28 UTC

Indentazione (Tabulazione)

matteo_susca — 2019-01-27 16:13:09 UTC

Decomposizione del codice utilizzano funzioni

matteo_susca — 2019-01-27 16:13:19 UTC

Inserimento di commenti esplicativi (definisce lo scopo della funzione significato dei parametri)

matteo_susca — 2019-01-27 16:13:24 UTC

Utilizzo di nomi significativi per le funzioni, le variabili e i parametri

matteo_susca — 2019-01-27 16:13:32 UTC

matteo_susca — 2019-01-27 16:13:35 UTC

La documentazione del codice è un insieme di istruzioni scritte che servono a descrivere il funzionamento del codice. Per essere di facile comprensione, oltre che ordinata e facilmente leggibile, viene scritte tramite l'uso di regole specifiche

Documentazione codice

matteo_susca — 2019-01-27 16:13:40 UTC

Spaziatura orizzontale e verticale

matteo_susca — 2019-01-27 16:16:01 UTC

Ambienti di sviluppo

matteo_susca — 2019-01-27 18:05:25 UTC

Editor

matteo_susca — 2019-01-27 18:08:40 UTC

Enfatizza la sintassi (parole chiave, identificatori, ecc…) e struttura (classi, funzioni) del codice
Evidenzia errori sintattici in fase di codifica o completa automaticamente le parole

I.D.E

matteo_susca — 2019-01-27 18:08:51 UTC

Integrated Development Enviroment

Debugger

matteo_susca — 2019-01-27 18:09:08 UTC

Permette l'esecuzione e il controllo degli errori nel codice e consente l'utilizzo dei breakpoint al suo interno. Permette inoltre di tenere sotto controllo il valore delle variabili.

Compilatore

matteo_susca — 2019-01-27 18:11:35 UTC

Permette la compilazione automatica di tutti i file di codice sorgente che costituiscono un programma
Riconduce / Associa i singoli messaggi di errore / avviso alla linea del codice che li ha generati

Susca e Talloni

matteo_susca — 2019-01-27 18:13:36 UTC

Gestione delle versioni del codice con Subversion

enea_filaseta — 2019-02-21 08:38:19 UTC

Versione

enea_filaseta — 2019-02-21 08:40:03 UTC

Un software è composto da diverse versioni e usualmente viene rappresentato con due cifre (es 1.0). Quando si crea una nuova versione o si implementano nuove funzioni nel codice, essa deve essere riconoscibile in base alle cifre che lo compongono.

Progettazione dei test

massimiliano_rabbi — 2019-02-21 08:41:15 UTC

Pianificazione e documentazione dei test

massimiliano_rabbi — 2019-02-21 08:42:22 UTC

- E' fondamentale per garantire che i test del SW siano eseguiti in modo esaustivo senza escludere la verifica di alcuna funzionalità o condizione
- L'attività dei test di un programma prevede una o più serie di casi di test (test case) . per ciascuno dei quali sono specificati:
1) Precondizioni per la corretta esecuzione del caso
2) Le azioni per l'esecuzione del test
3) I risultati attesi dall'esecuzione del caso e i criteri per dichiarare l'esito positivo o negativo

Version Control System (VCS)

matteogiorgini — 2019-02-21 08:42:28 UTC

Si utilizza un repository per la gestione delle versioni del codice.
Si scaricano i file dal repository per poterli modificare con il check-out.
Viene fatta una copia per modificarli.
Si esegue il commit per salvare nel repository il file modificato cambiando il numero della versione.

Test del Software e Tipologie di Test

eugenio_giraldi — 2019-02-21 08:42:50 UTC

Prima Cifra (Major Number)

enea_filaseta — 2019-02-21 08:47:42 UTC

Il software ha avuto un importante cambiamento nelle funzionalità del codice.

Test del Software

eugenio_giraldi — 2019-02-21 08:48:17 UTC

I test servono per controllare il corretto funzionamento del software e per garantire fattori di qualità (come affidabilità, usabilità o efficienza). Servono per provocare malfunzionamenti nel software. I test sulla qualità sono garantiti da:

Tipologie di Test

eugenio_giraldi — 2019-02-21 08:48:24 UTC

Black-Box: non consente un'analisi del codice, ma solo dell'interfaccia grafica. Questo test è progettato sulle direttive del cliente. Si cerca di approssimare il risultato alle aspettative del cliente. Gli errori possono essere causati da mala-comprensione o da mala-programmazione;
White-Box: permette l'analisi del codice. Il test deve permettere una copertura totale del codice da bug o errori di sistema;
Regressione: serve per testare la compatibilità di codice fatto da terze parti (che sia nuovo o antiquato e modificato). Il test serve per rilevare problemi di compatibilità;
Unitari: sono dei test eseguiti sulle singole untià del codice (ad esempio funzioni, if , for, ecc.). Questi test sono automatizzati perché è il compilatore stesso che rileva i bug;
Integrazione e Accettazione: si accerta il corretto funzionamento di tutte le unità di codice insieme.

Subversion

matteogiorgini — 2019-02-21 08:49:16 UTC

Viene utilizzato per la gestione delle versioni dei file.

Vengono mantenute le vecchie versioni.
Gestisce i codici in 2 modi differenti.

Seconda Cifra (Minor Number)

enea_filaseta — 2019-02-21 08:49:18 UTC

Serve per piccoli cambiamenti o per l' aggiunta di nuove piccole funzionalità nel codice.

Fase del test SW è finalizzata a:

massimiliano_rabbi — 2019-02-21 08:51:20 UTC

1) rilevazione dei malfunzionamenti
2) verifica della conformità ai requisiti del codice eseguibile

RISOLVERE BUG EVIDENZIATI DAL COMMITTENTE PUO' ESSERE MOLTO COSTOSO:
-> cliente senza SW (€€)
-> cliente scontento e quindi non torna

Nota Bene

enea_filaseta — 2019-02-21 08:53:39 UTC

1)La versione del codice non deve necessariamente essere 1.9 per passare alla 2.0.
2) Bisogna fare un back-up delle vecchie versioni del codice.

Lock - Modify - Unlock

matteogiorgini — 2019-02-21 12:08:50 UTC

Tecnica che impedisce a 2 sviluppatori la modifica dei file in contemporanea. Poco efficiente per il lavoro in parallelo.

Copy-Modify-Merge

enea_filaseta — 2019-02-21 12:08:54 UTC

Nella fase di write viene mandato un errore di conflitto se ci sono incongruenze nelle modifiche.
Chi deve eseguire il commit è tenuto a risolvere il conflitto.

massimiliano_rabbi — 2019-02-21 12:10:32 UTC

- Serve definire l'insieme dei casi di test
- Per ogni caso specifico:
1) dati di input
2) risultati attesi
3) descrizione dell'ambiente di esecuzione
- La batteria di test (test suite) è un insieme di casi di test
- Non esistono test validi in generale _ ogni test deve essere costituito su misura
- Dobbiamo tenere a mente:
1) la probabilità di rilevare un maggior numero di malfunzionamenti (aumenta proporzionalmente al n° di test eseguiti)
2) il controllo di qualità (test) ha un costo che bisogna tenere basso
3) test condotti in modo da valutare oggettivamente il risultato
4) dobbiamo definire l'oracolo che genera i valori con cui confrontare i risultati dei test per evidenziare i malfunzionamenti

Javadoc

nicola_talloni — 2019-02-21 12:12:38 UTC

Realizzata dalla Sun Microsystems nel 1990, insieme allo sviluppo del linguaggio Java, e ha il compito di documentare il proprio progetto.

matteo_susca — 2019-02-21 12:19:26 UTC

La javadoc è uno strumento che permette di documentare i codici sorgente di un programma all'interno dei codici sorgente stessi
Il programmatore inserisce nei codici sorgente, anziché scriverlo in un file separato, dei commenti con una particolare sintassi, che verrà mostrata in seguito tramite formato html

Progettazione test

eugenio_giraldi — 2019-02-21 12:20:18 UTC

I test possono essere pianificati alla raccolta dei requisiti;
Si individuano gli input che potrebbero dar problemi;
Il codice deve essere coperto al 100% da errori o bug, quindi devono essere testate tutte le funzionalità del programma.

Ambiente di test

eugenio_giraldi — 2019-02-21 12:20:36 UTC

Simula l'ambiente di esecuzione finale (ossia che verrà usato per far funzionare il programma).
È un ambiente a esecuzione controllata (terze parti non possono interferire con i test) che registra i comportamenti del software in base agli input forniti.
Permette l'esecuzione in conteporanea di più programmi e richiede la massima potenza di calcolo.
È configurabile e controllabile.

Analisi dei risultati

eugenio_giraldi — 2019-02-21 12:21:12 UTC

I dati, i risultati e i comportamenti registrati dall'esecuzione dei test nell'Ambiente di Test vengono confrontati con i risultati attesi e, in caso di discordie con questi, si cercano i punti sensibili e i problemi nel codice.

Debugging

eugenio_giraldi — 2019-02-21 12:23:15 UTC

I bug e gli errori individuati nelle analisi vengono risolti

Ripasso TPS

matteo_susca — 2019-02-24 17:13:55 UTC

matteo_susca — 2019-02-24 20:59:29 UTC

Il codice sorgente verrà analizzato e successivamente dopo l'esecuzione del "Parser" verrà generato un ipertesto HTML contenente le informazione contenute in tutti i tag "Javadoc" all'interno del codice.
All'interno si può trovare un indice, elenco dei metodi e altri strumenti per facilitare la consultazione del documento

Realizzazione di un Javadoc

nicola_talloni — 2019-02-24 21:00:36 UTC

Un commento in Javadoc è un testo HTML racchiuso tra i tag ' /** ' e ' */ '.
All'interno di questi tag sarà possibile scrivere descrizioni riguardanti il codice avvalendosi anche di uno o più tag tramite il simbolo " @ ". I tag possono descrivere Classi e Metodi e sono:

@author

matteo_susca — 2019-02-24 21:07:07 UTC

Aggiunge "Author: "

@version

matteo_susca — 2019-02-24 21:10:00 UTC

Aggiunge "Version: "

@see

matteo_susca — 2019-02-24 21:12:13 UTC

Aggiunge "See Also: "

Tags per Classi

nicola_talloni — 2019-02-24 21:13:27 UTC

@param [nome del parametro][descrizione]

matteo_susca — 2019-02-24 21:13:51 UTC

Aggiunge il nome parametro specificato e la sua descrizione

@return[descrizione]

nicola_talloni — 2019-02-24 21:16:16 UTC

Aggiunge "Returns" e la descrizione del valore di ritorno.

Tags per Metodi

nicola_talloni — 2019-02-24 21:18:29 UTC

@throws [nome completo della classe][descrizione]

matteo_susca — 2019-02-24 21:18:43 UTC

Aggiunge il nome dell'eccezione specificato e la sua descrizione

Criteri di progettazione dei test

davide_bacchiocchi — 2019-02-25 06:09:39 UTC

Criteri funzionali (black box)

davide_bacchiocchi — 2019-02-25 06:10:13 UTC

-si basano sui requisiti del programma;
-vengono testate le caratteristiche esterne del programma (interfaccia I/O e l' ambiente di esecuzione);
- devo definire un insieme di ingressi con i relativi esiti desiderati (per eseguire l' analisi con esiti).

Criteri strutturali (white box)

davide_bacchiocchi — 2019-02-25 06:10:48 UTC

- si basano sulla struttura del codice;
-testare ogni parte del codice;
-si basano sul flusso di controllo o del flusso dati di un programma.

davide_bacchiocchi — 2019-02-25 06:18:40 UTC

utilizzati per la progettazione di test e la realizzazione degli ambienti di test

davide_bacchiocchi — 2019-02-25 06:19:28 UTC

producono un insieme di dati di ingresso che è determinato dalla struttura del programma e non ha alcun legame con le sue funzionalità

Criteri funzionali+strutturali (gray box)

davide_bacchiocchi — 2019-02-25 06:19:33 UTC

spesso viene applicata una strategia con criteri sia funzionali che strutturali

davide_bacchiocchi — 2019-02-25 06:23:18 UTC

utilizzata per testare il programma conoscendo i requisiti e avendo limitata conoscenza della realizzazione, è fondamentale durante la realizzazione di un test l' esperienza del programmatore

Major Number

eneino01 — 2019-02-25 08:16:02 UTC

Viene cambiato questo numero quando si fanno modifiche importanti nelle funzionalità del codice.

Minor Number

eneino01 — 2019-02-25 08:17:56 UTC

Viene cambiato quando si fa manutenzione del codice o si fanno piccole modifiche alle funzionalità.