Approccio preferito per deridere un sito per testare un raschietto

3

Ogg. Atm Sto usando Selenium e Python, ma lo stesso vale per qualsiasi altra soluzione di scraping.

Mi chiedo:

  1. quali delle opzioni descritte di seguito sono ottimali / consigliate / best practice
  2. se esistono soluzioni / librerie helper esistenti, quali parole chiave dovrei cercarle.

Per rimanere obiettivi, "ottimali / consigliati / migliori pratiche" significa "ampiamente utilizzati e / o promossi / approvati da progetti di alto profilo nella nicchia".

Non sono riuscito a trovare materiale correlato al Selenio o di carattere generale su questo argomento dopo aver trascorso circa un giorno di ricerca in rete, il che probabilmente significa che mi mancano alcune parti critiche di informazioni.

Le operazioni di base durante lo scraping sono:

  • ricerca dell'elemento (dal selettore CSS / XPath e / o a mano per cose di cui non sono capaci)
  • interagendo con un elemento (inserisci testo, fai clic)
  • leggi i dati degli elementi

E la catena di chiamate va così:

(Test code ->) User code -> Framework (selenium) -> Browser (web driver) -> Site

Quindi qui ci sono 3 hop che potrei prendere in giro. Ognuno pone sfide:

  • Scherza il sito: avvia un server HTTP locale e indirizza il browser lì
    • Devono reimplementare l'interfaccia del sito raschiato, nelle tecnologie web
  • Scherza il browser (ad esempio, popola HtmlUnit (un motore di ricerca in-process) con l'HTML predefinito nei momenti appropriati)
    • molto più semplice, ma ancora bisogno di emulare transizioni di stato / reazioni di azione in qualche modo
  • Scherzi le chiamate del framework
    • Il più fedele alla filosofia di test delle unità, il meno lavoro
    • Sono tuttavia preoccupato che sia troppo restrittivo. Per esempio. Posso trovare lo stesso elemento con vari mezzi. Un oggetto fittizio può accettare solo una linea d'azione molto specifica in quanto manca la sofisticazione ad es. controlla se qualche altro selettore produce lo stesso risultato.

Ci sono anche due opzioni per il contenuto da fornire -

  • fornire il contenuto originale del sito che ha prodotto per una query di prova, compilandolo in un pacchetto di ordinamento o autonomo
    • laborioso e soggetto a errori o
  • fornisce il minimo indispensabile per soddisfare l'algoritmo testato
    • molto più semplice ma fallirebbe per altri possibili algoritmi che avrebbero avuto successo con il sito reale

Un'ultima preoccupazione è il fatto che un sito sia effettivamente una macchina a stati. Non sono sicuro che sarà più utile:

  • implementa la macchina a stati completa, probabilmente come una sorta di specifica, e imposta / controlla i suoi stati nei test
    • molto laborioso senza una sorta di libreria che riduce il lavoro a scrivere una specifica formale; o
  • convalida semplicemente le sequenze di azioni
    • che non sembra effettivamente testare il codice contro qualcosa - semplicemente ribadisce ciò che il codice fa

Aggiornamento per rispondere a una preoccupazione espressa:

Sto raschiando un sito di terze parti, che può cambiare e senza preavviso un giorno. Quindi, sto bene con i test contro "l'interfaccia del sito come era al momento della scrittura" - per verificare rapidamente se un cambio di codice ha rotto la logica interna del raschiatore.

    
posta ivan_pozdeev 05.02.2018 - 11:35
fonte

3 risposte

0

Un'idea data da @RobertHarvey in c796112 non è affatto il mock del sito.

Se l'obiettivo è di testare la logica interna del raschietto, prova esattamente questo:

  • Suddividi il codice che implementa direttamente le operazioni delle pagine elementari in subroutine e prendi in giro quelle.
    • L'idea è di rendere queste subroutine il più semplici possibile (in effetti, un selettore glorificato / XPath) in modo che possano fare a meno del testing.

Sul tuo schema, questo sarà un gradino più in alto rispetto all'hop "User code - > Framework": User code -> Elementary page operations -> Framework .

    
risposta data 11.02.2018 - 03:58
fonte
1

Puoi diventare pazzo e deridere ogni dettaglio. Probabilmente non è fattibile dato molti casi di test complicati.

Ove possibile, è meglio registrare un input di prova del mondo reale completo, redarlo per eliminare dettagli irrilevanti e quindi eseguirlo attraverso il motore di scraping completo. Come rappresentare il sito e come riprodurlo dipende dalla fedeltà di cui hai bisogno per questi test. Per esempio. questo potrebbe essere molto difficile se si prevede che il sito faccia richieste Ajax a più domini.

Ad esempio, potresti scappare semplicemente memorizzando l'HTML di una pagina che vuoi analizzare. In casi estremi, è necessario registrare e riprodurre tutte le richieste HTTP effettuate dal sito. Ad esempio, il sito effettua la richiesta e tu riproduci una risposta che hai registrato dal sito live.

In tutti i casi, la cosa che asserisci è che il tuo raschietto ha estratto i dati corretti dalla pagina. Come ci sarà sarà secondario.

Il vantaggio di questi metodi di test di alto livello è che

  • sono abbastanza realistici,
  • e una volta che la suite di test è stata impostata, aggiungere un altro test non richiede molto sforzo.

Lo svantaggio è che questi test sono un po 'lenti - molto più veloci rispetto alle richieste effettive di siti live, ma ancora più lenti dei test unitari mirati del raschietto.

Nel tempo, puoi far crescere un corpus di casi di test realistici. Se un caso di test smette di essere utile (ad esempio perché il sito live è cambiato), puoi sempre eliminarlo.

    
risposta data 10.02.2018 - 21:34
fonte
0

Non sono sicuro di cosa intendi con raschietto qui. Quando sviluppo l'automazione dell'interfaccia utente utilizzando Selenium / Java, definisco i test delle unità. Diciamo che ho l'applicazione web e scrivo test sul selenio per verificare il login, il login non valido, ecc. Quindi provo davvero un'applicazione web esistente che funziona per avvisare che qualcosa è andato storto o è andato in pezzi, è andato fuori sincrono con quello che ci aspettiamo. / p>

D'altra parte stavo scrivendo raschietti che non era necessariamente basato sul selenio. Le chiamate Http di base sono state utilizzate da me per visitare le pagine, recuperare il codice HTML, estrarre i dati utilizzando espressioni regolari e archiviare i dati in csv / json e quindi elaborati, ad esempio per raccogliere i prezzi di hotel o negozi.

I mazzi in java servono a simulare le dipendenze per eseguire i test unitari separatamente. Diciamo che abbiamo un'operazione di ATM e invece di inserire la vera carta, mostrando il vero equilibrio, creiamo un oggetto fittizio per bankService per restituire il bilanciamento predefinito, inseriamo una carta "simulata" in ATM con dati predefiniti, ecc. Lo scopo dei mock è di testare l'unità senza ritardi. Non capisco cosa voglia dire raschietto e falso sito. Il sito sarà costruito, ma non sul posto? Bene, scrivi i test sul selenio e poi definisci i nomi degli elementi corretti e abilitalo quando il sito è attivo e funzionante.

Non capisco lo scopo del sito di mock, perché solitamente gli sviluppatori eseguono l'istanza locale del server per lo sviluppo. Esistono ambienti di produzione dev, qa.

Bene, lavorando nel team di QA praticamente stavamo coprendo quello che c'è, quindi controlla lo scenario predefinito e ci avvisa quando qualcosa va giù o è stato rotto da dev. O lo usi per lo sviluppo basato sui test. Quando si definiscono le regole aziendali e mentre si implementano, molte cose diventano verdi e superano il test.

Penso che con il selenio testi solo la tua parte dell'interfaccia utente. Questa è la versione automatica di ciò che fanno i tester manuali.

Il lato server è coperto da test di unità, test di integrazione, testimoni di unità nei test di unità per verificare il comportamento del codice finale, ma non ha alcuna relazione con il selenio. Il selenio è per i test dell'interfaccia utente.

    
risposta data 05.02.2018 - 21:17
fonte

Leggi altre domande sui tag