SQLancer è uno strumento per testare automaticamente i sistemi di gestione di database (DBMS) al fine di trovare bug nella loro implementazione. Cioè, individua bug nel codice dell'implementazione del DBMS, non nelle query scritte dall'utente. SQLancer ha trovato centinaia di bug in DBMS maturi e ampiamente conosciuti.

SQLancer affronta due sfide essenziali nel test automatico dei DBMS:

1. Generazione degli input di test: SQLancer implementa approcci per generare automaticamente istruzioni SQL. Contiene vari generatori SQL scritti a mano che operano in più fasi. Prima viene creato uno schema del database, che si riferisce a un insieme di tabelle e alle loro colonne. Quindi, i dati vengono inseriti in queste tabelle, insieme alla creazione di vari altri tipi di stati del database come indici, viste o opzioni specifiche del database. Infine, vengono generate query, che possono essere validate utilizzando uno dei molteplici validatori di risultati (chiamati anche oracoli di test) forniti da SQLancer. Oltre all'approccio standard di creare le istruzioni in modo non guidato, SQLancer supporta anche un approccio di generazione degli input di test guidato dal feedback, che mira a esercitare quanti più piani di query unici possibile, basandosi sull'intuizione che ciò eserciterebbe molti comportamenti interessanti nel sistema di database [ICSE '23].
2. Oracoli di test: Un'innovazione chiave di SQLancer è che fornisce modi per trovare tipi profondi di bug nei DBMS. Come focus principale, può trovare bug logici, ovvero bug che causano il recupero di un insieme di risultati errato da parte del DBMS (ad esempio, omettendo un record). Abbiamo proposto molteplici oracoli di test complementari come Ternary Logic Partitioning (TLP) [OOPSLA '20], Non-optimizing Reference Engine Construction (NoREC) [ESEC/FSE 2020], Pivoted Query Synthesis (PQS) [OSDI '20], Differential Query Plans (DQP) [SIGMOD '24], e Constant Optimization Driven Database System Testing (CODDTest) [SIGMOD '25]. Può anche trovare categorie specifiche di problemi di prestazioni, che si riferiscono a casi in cui ci si potrebbe ragionevolmente aspettare che un DBMS produca il suo risultato in modo più efficiente utilizzando una tecnica chiamata Cardinality Estimation Restriction Testing (CERT) [ICSE '24]. SQLancer può rilevare errori interni inaspettati (ad esempio, un errore che indica che il database è corrotto) dichiarando tutti i potenziali errori che potrebbero essere restituiti da un DBMS per una determinata query. Infine, SQLancer può trovare bug di crash, che sono bug che causano la terminazione del processo del DBMS. Per questo, utilizza un oracolo di test implicito.

Community. Abbiamo uno Slack workspace per discutere di SQLancer e del test dei DBMS in generale. In precedenza, SQLancer aveva un account su Twitter/X @sqlancer_dbms, che non è più mantenuto. Abbiamo un blog, che, al momento, contiene solo post dei contributori del progetto Google Summer of Code.

Per Iniziare [Video Guide]

Requisiti minimi:

• Java 11 o superiore
• Maven

I seguenti comandi clonano SQLancer, creano un JAR e avviano SQLancer per testare SQLite utilizzando Non-optimizing Reference Engine Construction (NoREC):``` git clone https://github.com/sqlancer/sqlancer cd sqlancer mvn package -DskipTests cd target java -jar sqlancer-*.jar --num-threads 4 sqlite3 --oracle NoREC

**Esecuzione e terminazione.** Se l'esecuzione stampa informazioni di avanzamento ogni cinque secondi, allora lo strumento funziona come previsto. La scorciatoia CTRL+C può essere utilizzata per terminare SQLancer manualmente. Se SQLancer non trova alcun bug, viene eseguito all'infinito. L'opzione `--num-tries` può essere utilizzata per controllare dopo quanti bug SQLancer termina. In alternativa, l'opzione `--timeout-seconds` può essere utilizzata per specificare la durata massima di esecuzione consentita a SQLancer.

**Parametri.** Se si avvia SQLancer senza parametri, vengono visualizzate le opzioni e i comandi disponibili. Nota che le opzioni generali supportate da tutte le implementazioni di test DBMS (ad es. `--num-threads`) devono precedere il nome del DBMS da testare (ad es. `sqlite3`). Le opzioni supportate solo per uno specifico DBMS (ad es. `--test-rtree` per SQLite3), o le opzioni per cui ogni implementazione di test fornisce valori diversi (ad es. `--oracle NoREC`) devono andare dopo il nome del DBMS.

**DBMS.** Per eseguire SQLancer su SQLite, non è stato necessario installare e configurare un DBMS. Il motivo è che i DBMS embedded vengono eseguiti nello stesso processo dell'applicazione e quindi non richiedono installazione o configurazione separata. I DBMS embedded supportati da SQLancer includono DuckDB, H2 e SQLite. I loro binari sono inclusi come [dipendenze JAR](https://github.com/sqlancer/sqlancer/blob/main/pom.xml). Nota che eventuali crash in questi sistemi causeranno anche un crash nella JVM su cui SQLancer è in esecuzione.

# Utilizzo di SQLancer

**Log.** SQLancer memorizza i log nella sottodirectory `target/logs`. Per impostazione predefinita, l'opzione `--log-each-select` è abilitata, con il risultato che ogni istruzione SQL inviata al DBMS viene registrata. I nomi dei file corrispondenti hanno il suffisso `-cur.log`. Inoltre, se SQLancer rileva un bug logico, crea un file con estensione `.log`, in cui vengono registrate le istruzioni per riprodurre il bug, incluse solo l'ultima query eseguita insieme alle altre istruzioni per impostare lo stato del database.

**Riduzione dei bug.** Dopo aver trovato un input di test che induce un bug, l'input tipicamente deve essere ridotto per essere ulteriormente analizzato, poiché potrebbe contenere molte istruzioni SQL ridondanti per riprodurre il bug. Un'opzione è farlo manualmente, rimuovendo un'istruzione o una caratteristica alla volta, rieseguendo le istruzioni che inducono il bug e applicando l'oracolo di test (ad esempio, per oracoli di test come TLP o NoREC, ciò richiederebbe di verificare che entrambe le query producano ancora un risultato diverso). Questo processo può essere automatizzato utilizzando un cosiddetto [approccio di delta-debugging](https://www.debuggingbook.org/html/DeltaDebugger.html). SQLancer include un'implementazione sperimentale di un approccio di delta-debugging, che può essere abilitata usando `--use-reducer`. In passato, abbiamo utilizzato con successo [C-Reduce](https://embed.cs.utah.edu/creduce/), che richiede di specificare l'oracolo di test in uno script eseguibile da C-Reduce.