Ciao, Habr! Noi di Wrike stiamo testando nuovi formati per eventi tecnici e invitiamo tutti a guardare il video del nostro primo incontro online in inglese. sull'infrastruttura DevOps per testare applicazioni web, cubi, Selenium e le sue alternative.
La storia della diffusione del coronavirus e i divieti di tutti gli eventi offline di massa nei paesi europei hanno apportato modifiche, quindi l'incontro offline di tester e sviluppatori pianificato da Wrike Praga si è esteso a YouTube.
Attenzione, i resoconti sono in inglese.
1. Mikhail Levin, Wrike – Selenium – strada verso Kubernetes
C'era una volta il Selenio che viveva e cresceva. Probabilmente è stata la cosa migliore accaduta per l'automazione del QA negli ultimi due decenni e sì, non è stato facile in molti modi, comprese le infrastrutture e la stabilità.
Con una lunga esperienza nelle infrastrutture e nelle alternative della rete al selenio, voglio guidarti attraverso alcuni problemi e limiti delle diverse infrastrutture al selenio fino alla nostra nuovissima soluzione leggera.
2. Vitaliy Markov, Wrike – Callisto: come abbiamo imparato a smettere di preoccuparci e ad amare il selenio
Ti presentiamo Callisto: la nostra soluzione nativa Kubernetes leggera e open source per la creazione dell'infrastruttura Selenium. Eseguiamo decine di migliaia di test sul selenio in un'ora e sopravviviamo a centinaia di test giornalieri sul selenio. Vogliamo condividere le nostre ragioni, la soluzione stessa e i dettagli tecnici appresi lungo il percorso. La nostra esperienza potrebbe tornare utile se esegui molti test sul selenio o hai semplicemente del lavoro basato su sessioni da eseguire in k10 in molti thread.
3. Ivan Krutov, Aerokube – Protocollo Chrome Developer Tools: esecuzione e scalabilità in Kubernetes
Da molti anni Selenium è lo strumento di automazione del browser più popolare. Tuttavia, il protocollo Selenium manca ancora di molte funzionalità importanti: analisi e derisione delle richieste HTTP, acquisizione di parametri relativi al consumo di memoria e alle prestazioni, sottoscrizione agli eventi dell'applicazione, recupero degli avvisi di sicurezza del browser e molto altro. Fortunatamente, tutto questo è già supportato nel cosiddetto protocollo Chrome Developer Tools. Si parla molto su come iniziare a utilizzare questo protocollo con librerie client come Puppeteer, ma quasi nessuno spiega come scalare questa soluzione. Durante il mio intervento, vorrei spiegare come scalare gli strumenti per sviluppatori di Chrome nel cluster Kubernetes e mostrare alcuni esempi reali di come potresti utilizzare questo protocollo nei tuoi test.
Fonte: habr.com