Please enable JavaScript.

Coggle requires JavaScript to display documents.

Concetti generali - Coggle Diagram

- - - - Maven include le seguenti fasi:
        
        validate: tutte le info sono disponibili?
        
        compile: compilo sorgente
        
        test: provo i test
        
        package: creo JAR
        
        integration test: faccio package in ambiente dove test integrazione eseguibili
        
        verify: vedo se package rispetta i criteri di qualità
        install: installo package per usarlo
        
        deploy: copio in repo remota
        
        clean: pulizia artefatti/target
        
        site: genero documentazione
    - - Con approccio devOps ogni commit può essere l'ultimo.
        
        Come costruisco un insieme di test buono per rivelare errori?
        
        Obiettivo : ho un programma da testare SUT, con un dominio di input D, di cui considero un insieme più piccolo Tx che identifica errori Ex, in funzione di un budget B.
        Voglio creare Tg (minimale) che rientri nel budget, e rispetto altri gruppi di test trovi più errori e sia di dimensioni uguali/minori.
        
        Come trovo Tg?
        
        RANDOM
        :check: semplice
        :check: utile quando mi approccio alla prima volta ad un test
        :check: può rilevare errori grossolani
        :red_cross: ricerca senza metodo
        :red_cross: devo fare piu test per avere una certa confidenza.
        
        CATEGORY
        individuo classi di equivalenza, ed eleggo un rappresentante. Queste classi sono influenzate dalla documentazione, familiarità col SUT, etc.., a volte è il nome di un elemento che mi suggerisce (ma non è detto sia valido!)
        
        TIPI DI APPROCCIO
        
        UNIDIMENSIONALE: Ogni parametro è indipendente, quindi mi basta che sia preso almeno una volta, non mi interesse se da solo o con altri.
        
        MULTIDIMENSIONALE: prodotto cartesiano dei parametri multidimensionali.
        
        In ogni caso, nei miei test ho sempre un output atteso, e anche se uso approccio unidimensionale potrei mettere più test che per me sono significativi. Devo sempre fornire risultato atteso.
      - CONCETTI DI UNIT/INTEGRATION TESTING
        
        V-MODEL
        
        Test e requisiti vengono usati per validare il prodotto, per vedere se sistema funziona e fa ciò che serve.
        In realtà nulla mi vieta di analizzare i singoli pezzi.
        
        Nel V-Model abbiamo le due 'linee' componenti la V che indicano un approccio sequenziale da parte del designer e del tester, fino al merge per il codice finale. In realtà ad ogni 'altezza' del v-model avviene uno scambio di informazioni.
        
        Il designer specifica ed implementa le funzionalità, rilasciandole al tester, il quale specifica ed implementa test che poi eseguirà. Ciò normalmente avviene quando al rilascio di nuove funzionalità/versioni, ma anche ad ogni commit o pull request
        
        Un'altra prospettiva ribalta il modello, partendo dal basso ho Unit, Integration, System, Acceptance (cosa chiede l'utente)
        
        Test di unità
        
        Lo scopo è rivelare malfunzionamenti ed acquisire confidenza, possono essere scritti anche prima del codice (Test Driven Develop), mentre l'adeguatezza è vista o in base al numero di funzionalità controllate, o in base a metriche di 'copertura'.
        
        Strategie per Integration Testing
        
        Innanzitutto si assume di operare in un modulo del SUT isolato, trovare soluzione ottima è problema NP completo. Esistono varie strategie:
        
        big-bang: testo quando ho tutti i moduli disponibili, quindi testo tardi perchè aspetto tutti.
        
        top-down : utile sopratutto per integrare interfacce attese/previste, usando funzionalità più generali. Se voglio che C1 (under-test) mandi msg a C2, e lavoro su C1 creo uno 'stub/mock' di C2, che sono come delle 'marionette' passive (non stimolano). Qui è C1 che chiama C2.
        
        bottom-up : qui parto dai bordi, non servono stub ma test driven (attivo) per lo stimolo, testo unità elementari. Parto dalle foglie e salgo. Qui è c2 che viene chiamata da C1.
        
        Plugin Maven
        
        Surefire Plugin: per gli unit test, utile per lanciare test in un unico modulo maven (Junit sta 'sotto'). Le classi di test devono includere 'Test' nel nome, e i report sono nella cartella target
        
        Failsafe Plugin: utile per test su più progetti/moduli. Attivato con verify maven.
        
        ADEGUACY CONTROL FLOW
        
        COME SONO I MIEI TEST?
        
        Esistono approcci funzionali black-box e strutturali white-box.
        
        I funzionali richiedono documentazioni, che ci informa del comportamento di un'entità.
        Mi concentro su COSA deve essere fatto per stabilire l'adeguatezza, senza percorrere tutti i rami, inoltre sono sempre 'sotto' un determinato contesto/sistema, se cambiato il criterio perde valore.
        
        Gli strutturali sono basati sulla copertura del codice, non funzionalità, sono più automatizzabili, ma di minor interesse all'utente, non evidenzia funzioni mancanti.
        
        CRITERI CONTROL FLOW
        In generale ci preoccupiamo che i nostri test coprino i nodi del grafo risultante dal codice.
        
        Statement coverage:
        rapporto tra linee codice coinvolte in un test/(istruzioni totali - istruzioni non raggiungibili dal SUT).
        
        Block coverage :
        rapporto tra blocchi coinvolti in un test / (blocchi totali - blocchi irraggiungibli)
        
        Decision coverage :
        rapporto tra insieme degli if percorsi (per ogni alternativa) / (punti if totali - non raggiungibili).
        
        Condition coverage:
        insieme di condizioni validate (devo coprire ogni singola componente) / (totali - non raggiungibili dal sut). Vedo sia condizioni semplice T/F che complesse. A causa della Lazy evalution non uso AND ma OR
        
        La differenza tra gli ultimi due è che nel branch mi interessa il caso: entro nell'if /non entro nell'if,
        mentre nel condition mi interessa che ogni componente dell'if sia true e poi false (se poi non entro non mi interessa). Nessuna delle due implica l'altra.
        
        branch condition coverage:
        insieme delle precedenti (metto insieme numeratori e denominatori), rispetto punti di scelta E espressioni semplici/atomiche, insieme di condizioni e decisioni.
        
        multiple condition coverage :
        utile se mi interessano le condizioni complesse, senza esplorare totalmente, ho insieme condizioni validate/(combinazioni totali - non raggiungibili)
        
        MC/DC
        copro tutti i punti di scelta e tutte le espressioni evitando l'esplosione combinatoria degli stati, richiede che:
        
        ogni blocco sia coperto
        
        condizioni semplici sempre coperte da T e F
        
        ogni decisione è coperta per ogni ramo
        
        ogni condizione complessa nel SUT è composta da condizioni semplici e indipendenti.
        
        Queste 3 condizioni implicano block coverage = condition coverage = branch decision coverage = 1
        allora
        MCDC = numero di condizioni semplici indipendenti/ (sommatoria di condizioni semplici tot - semplici non soddisfacibili)
        
        DATA-FLOW
        
        Si basa sul concetto di <def,use>.
        Una variabile può essere usata in un predicato come if (p-use), o per computazioni (c-use).
        
        Ispezionando il grafo definiremo poi insieme DCU per c-use (coppia di nodi raggiungibile in modo computazionale), e l'insieme DPU per p-use (che opera per i predicati).
        
        Anche qui esistono metriche:
        C-USE coverage : c-use coperte da tutte le variabili / (dcu - c-use non raggiungibili).
        P-USE coverage : analogo
        
        Posso fare anche all coverage mettondo insieme numeratori e denominatori di entrambe
        
        X-MEN
        
        Per individuarlo deve essere:
        
        raggiungibile: esiste path di esecuzione che ci arriva
        
        infezione stato: M != SUT (ovvero il sut deve essere infettato per far esistere il mutante)
        
        propagazione stato: l'impatto del mutante si protrae fino alla fine dell'esecuzione considerata.
        
        M = SUT se non esiste almeno un caso di test che rispetta le 3 condizioni.
        Esiste strong mutation (stessi risultati del SUT) e weak mutation (implica strong, presenta stessi stadi intermedi).
        Ad esempio M porta stesso risultato di SUT, ma segue percorso diverso (strong ma non weak).
        
        Esiste anche qui mutation score:
        
        mutanti rivelati/(mutanti vivi + morti)
        oppure
        mutanti rivelati/(tutti mutanti - equivalenti al sut) , più preciso ma piu difficile.
  - - - AUTOMATED TESTING
        
        parola chiave automazione, per i test, per la prioritizzazione, per la bontà, in modo da migliorare efficienza/efficacia del QA, riducendo costi e durata test
      - Se ho loro allora parlo di Continuous Testing, in cui i test vengono eseguiti per ogni evoluzione della code base, integrando i processi di QA (testing)