Risk Based Software Test Prioritization Using Machine Learning Defect Prediction on Five Open Source Repositories
Questo articolo espone una fatale circolarità tra etichetta e caratteristica nel tipico software testing basato sul rischio che gonfia le prestazioni del machine learning, per poi proporre un protocollo rigoroso che utilizza la rimozione delle caratteristiche fugaci e una valutazione rigorosa per dimostrare un modesto ma statisticamente robusto miglioramento del 3,64% rispetto a baseline forti, rivelando al contempo che tali modelli non sono in grado di generalizzare temporalmente.
Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Nel vasto e mutevole panorama dello sviluppo software moderno, il codice viene scritto, testato e aggiornato a una velocità che sopraffarebbe qualsiasi team umano. Per tenere il passo, gli ingegneri si affidano a sistemi automatizzati che eseguono migliaia di controlli ogni volta che viene apportata una modifica. Questi controlli, noti come test, sono la rete di sicurezza che intercetta gli errori prima che raggiungano gli utenti. Tuttavia, man mano che il software cresce, anche il numero di test cresce ancora più velocemente, diventando infine così elevato che eseguire ogni singolo controllo richiede troppo tempo. Aspettare un ciclo completo di controlli può ritardare il rilascio di nuove funzionalità per ore, rallentando l'intero processo creativo. Ciò crea un difficile dilemma: i team hanno bisogno di essere veloci, ma non possono permettersi di saltare i controlli di sicurezza. La soluzione a cui molti si sono rivolti è il testing basato sul rischio, una strategia che cerca di indovinare quali parti del codice siano più probabili che si rompano e le controlla per prime. La speranza è quella di trovare gli errori rapidamente senza sprecare tempo sulle parti del sistema che sono stabili.
Per anni, i ricercatori hanno cercato di insegnare ai computer di fare queste ipotesi utilizzando il machine learning, un metodo in cui il software impara modelli dai dati passati. Hanno fornito ai computer informazioni su come i file sono stati modificati, chi li ha modificati e con quale frequenza. L'obiettivo era costruire un modello che potesse guardare un file e dire: "Questo è rischioso; controllalo per primo". Ma un nuovo studio del ricercatore indipendente Vijay Prasad Javvati rivela che molti di questi tenti precedenti erano basati su un errore fondamentale. Lo studio mostra che i dati stessi usati per insegnare al computer cosa rende un file "buggy" (propenso a errori) erano spesso gli stessi dati usati per fare la previsione. Era come chiedere a uno studente di prevedere il voto di un esame mentre gli si consegna segretamente il copione delle risposte come guida allo studio. Il computer non stava imparando a prevedere il futuro; stava semplicemente leggendo l'etichetta che doveva indovinare.
Javvati ha cercato di risolvere il problema rimuovendo la fuga di dati (data leakage) e ricominciando da zero con un insieme di regole pulite. Ha raccolto dati da cinque grandi e famosi progetti open-source, esaminando quasi trecentomila file. Nel vecchio metodo difettoso, al computer veniva detto che un file era "propenso ai difetti" se fosse mai stato corretto per un bug, e poi gli veniva fornito il conteggio esatto di quelle correzioni come indizio per fare la sua previsione. Javvati ha rimosso questi indizi fuorvianti. Ha costretto il computer a fare affidamento solo su altri segnali, come quante volte un file è stato toccato, quante persone diverse ci hanno lavorato e quanto codice è stato aggiunto o rimosso. Ha poi confrontato questi modelli intelligenti con un approccio molto semplice e non intelligente: ordinare semplicemente i file in base a quante volte sono stati modificati.
I risultati sono stati rivelatori. Quando gli indizi fuorvianti sono stati rimossi, i complessi modelli di machine learning non sono crollati, ma non hanno nemmeno compiuto miracoli. Il modello più intelligente, un tipo di algoritmo chiamato Random Forest, è riuscito a identificare circa il 46,5 percento dei file difettosi guardando solo il 10 percento di quelli più sospetti. Questo era un reale miglioramento, ma era modesto. Più importante ancora, il metodo semplice di contare semplicemente quante volte un file era stato modificato era quasi altrettanto efficace, intercettando circa il 43 percento dei file errati. Il modello intelligente ha ottenuto solo un piccolo vantaggio di circa tre o quattro punti percentuali rispetto al conteggio semplice. Ciò suggerisce che, sebbene il machine learning possa aiutare, il segnale più potente per trovare i bug è spesso la semplice cronologia grezza di quanto un file sia stato modificato.
Lo studio ha anche scoperto una sorprendente limitazione su quanto lontano possano spingersi queste previsioni nel futuro. Quando i ricercatori hanno provato a testare i modelli su file completamente nuovi — file che erano stati appena creati e che non avevano ancora avuto il tempo di accumulare una cronologia di modifiche — i modelli sono falliti completamente. Non erano migliori del caso casuale. Questo accadeva perché la definizione di un file "buggy" dipendeva da una cronologia di correzioni passate. Un file nuovo non ha una cronologia, quindi il modello non aveva modo di sapere se sarebbe diventato problematico. Questa scoperta funge da avvertimento: questi strumenti sono eccellenti nel descrivere quali file sono attualmente rischiosi in base al loro passato, ma non possono prevedere in modo affidabile quali nuovi file diventeranno rischiosi domani.
In definitiva, questa ricerca offre un quadro più chiaro e onesto di come dare priorità al testing del software. Conferma che i vecchi metodi erano gonfiati da un difetto nascosto, ma dimostra anche che un approccio corretto mantiene comunque il suo valore. La strada migliore per i team di ingegneria non è affidarsi a previsioni complesse e "black-box", ma utilizzare una combinazione di segnali semplici e comprensibili e un modello di machine learning leggero. Lo studio raccomanda l'uso di un tipo specifico di algoritmo veloce che possa fare una previsione in meno di un millisecondo, permettendogli di essere eseguito istantaneamente mentre uno sviluppatore scrive. Questo approccio non promette di catturare ogni errore, ma fornisce un modo statisticamente solido per concentrare il tempo di testing limitato sui file che più probabilmente ne avranno bisogno, bilanciando la necessità di velocità con la necessità di sicurezza.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.