Generazione di dati di test per un'applicazione di ricerca

1

Ho una domanda generica su come testare le applicazioni di ricerca, e quello che sto cercando sono i riferimenti alle risorse sull'argomento che posso andare a fare ricerche per conto mio. Ho provato la google semi-informata, semi-non orientata, ma questo ha comportato un sacco di distrazioni e vicoli ciechi (o forse le mie capacità di ricerca non sono poi così nette).

Prima un po 'di setup. Quando dico "un'applicazione di ricerca", intendo questo:

  • hai alcune origini dati che puoi mettere insieme in un indice di ricerca
  • la tua applicazione ha un'API che accetta come input una query di ricerca (parole chiave e, facoltativamente, altre cose), e il suo risultato è un elenco di risultati in ordine di rilevanza dall'indice di ricerca.
  • c'è tutta una serie di business logic oltre al semplice recupero dei risultati dall'indice - il risultato finale impostato nell'output potrebbe avere una grande distanza di modifica dal set di risultati originale della ricerca.
  • supponiamo che nella realtà, l'indice sia grande e impieghi un po 'di tempo a costruire

L'attività è scrivere test per l'applicazione. La struttura di base di un test è "data la richiesta di ricerca X, mi aspetto che la risposta Y sia costituita da risultati ordinati per pertinenza". Il problema, quindi, è: qual è una buona strategia per generare i dati sottostanti per i test?

Ecco alcuni approcci di cui sono a conoscenza (e che ho usato in pratica):

  • Non generare dati di test. Inizia con un indice reale e applica modifiche mirate ad esso per "introdurre" i casi limite per i test in base alle esigenze. Upside: vicino alla vita reale. Aspetti negativi: grande indice di prova; deve essere ricostruito ogni volta che viene apportata una modifica allo schema di indicizzazione; la maggior parte non è utilizzata dai casi di test esistenti.
  • Genera dati falsi in modo che per ogni richiesta X sia presente un insieme di risultati Y ben definito e intenzionalmente costruito che verrà restituito. Aspetti positivi: pieno controllo sui dati di ricerca; solo la quantità di dati necessaria per i test, più rapida e facile da modificare. Aspetti negativi: devono ancora ricostruire tutto nelle modifiche dello schema di indicizzazione; dati non necessariamente realistici, che potrebbero lasciare gli aspetti del sistema non testati o sottovalutati; troppa flessibilità e conoscenza del dominio specifica per il test separata dal dominio reale dell'applicazione.

In realtà è qui che finisce la mia conoscenza attuale. Qualcosa mi dice che c'è una buona via di mezzo che consente di testare la flessibilità senza deviare dal modo in cui l'applicazione funziona nella vita reale, o un approccio di test completamente diverso che elimina queste preoccupazioni. Quali approcci potresti prendere in considerazione?

    
posta RuslanD 02.12.2014 - 04:07
fonte

3 risposte

1

Risposta breve: hai bisogno di entrambi

  • dati falsi, con input X ben definito e output Y
  • dati del mondo reale, probabilmente con le modifiche che hai suggerito

Usa il primo specialmente quando fai TDD (come indicato dal tuo tag), e dopo aver pronto l'algoritmo di base, usa il secondo tipo di dati per i test di integrazione o di accettazione. Il primo tipo di test ti impedirà di eseguire il secondo tipo di test (probabilmente lento) più spesso del necessario.

Something tells me there is either a nice middle ground which allows for testing flexibility without deviating from how the application works in real life or a completely different testing approach

Ci dispiace, ma finora non esiste un "magic bullet". Testare algoritmi complessi è un lavoro duro, a volte difficile, che richiede competenze analitiche. Esistono interi libri scritti su come costruire efficientemente i casi di test e le tecniche descritte, ad esempio, di Glenford Myers nel suo libro sui test del software , che è stato pubblicato per la prima volta nel 1979 AFAIK, sono ancora validi oggi.

    
risposta data 02.12.2014 - 06:37
fonte
0

Non è chiaro per me cosa si provi a fare, può essere una delle due cose molto diverse che si desidera testare e non è necessario raggrupparle insieme:

  1. Verifica che qualcosa non sia terribilmente rotto con il tuo sistema, ad esempio "scrivi test". In questo caso, è meglio se generi un corpus di documenti finto (probabilmente relativamente piccolo) che indichi e scriva test di precisione / richiamo contro questo.

  2. Misurare effettivamente le prestazioni del "sistema di ricerca" nel senso di misurare "quanto bene serve l'utente nella vita reale". Per esempio. questo è qualcosa che probabilmente farai se vuoi, per esempio, costruire un concorrente su Google (vorrai valutare quanto è buona la tua ricerca rispetto a Google, oppure, se stai già lavorando su Google, tu "Voglio misurare" quanto è buono il mio nuovo algoritmo Hummingbird, rispetto a Panda e Penguin? "). Se questo è ciò che misurate, allora questo è un obiettivo completamente diverso, e non dovreste misurare nulla di sintetico, ma invece dovreste misurare il comportamento effettivo dell'utente. Ci sono AFAIK due misure di prestazione ampiamente accettate (e utilizzate):

    2.a Misura il "tempo di risposta" per l'utente tipico (quanto tempo impiega un utente del sistema a "riuscire"? Questo è particolarmente applicabile dove si ha una buona misura per il successo - per esempio se stai lavorando per un sito di fotografia stock, il successo potrebbe significare "l'immagine è stata scaricata o aggiunta alla lista dei desideri"). Si noti che è probabile che l'utente esegua più di una query in una singola sessione, in realtà si suppone che tutte quelle query siano correlate e che l'utente possa avere difficoltà a esprimere le proprie necessità e possa provare ricerche diverse, tutte con lo stesso obiettivo .

    2.b Misura la media della precisione media (vedi link per una definizione rapida e link per una semplice spiegazione di cosa sia realmente MAP).

Nell'articolo di Wikipedia troverai altre prestazioni e amp; misure di correttezza, ma questi due sono tutto ciò che devi sapere:)

    
risposta data 02.12.2014 - 15:13
fonte
0

What is a good strategy for generating the underlying data for the tests?

Vorrei utilizzare una versione modificata del secondo approccio:

Genera dati falsi in modo che per ogni richiesta X sia presente un insieme di risultati Y ben definito, intenzionalmente costruito che verrà restituito.

Ma invece di interrogare direttamente il database, il tuo motore di ricerca dovrebbe essere implementato su repository-interface a>

Ogni interfaccia di repository ha un'implementazione che utilizza il database e un'implementazione falsa in grado di leggere il risultato da un file di testo leggibile. In questo modo i tuoi dati test sono meno dipendenti dalle modifiche dello schema del database.

  • Durante il test del motore di ricerca viene utilizzato il repository falso.
  • Per ogni test è disponibile un file di risposta specifico per il test che può essere gestito con un editor di testo.
risposta data 02.12.2014 - 17:46
fonte