Commenti iniziali
Tony Voellm (Google)
Link: Video
Discorso di apertura - Evoluzione dal controllo qualità all'ingegneria dei test
Ari Shamash (Google)
Hai creato un'app. L'hai avviata. Hai pensato di farcela, aumentare il volume della campagna, ottenere fondi, lanciare il tutto e iniziare da zero, in modo da poterlo fare nel modo giusto. Tuttavia, le esigenze di nuove funzionalità sono talmente elevate che ora ti viene chiesto di passare a una scalabilità senza precedenti a una velocità senza precedenti. Accidenti! e ti stai chiedendo cosa fare adesso?
Non puoi gettarlo via e ricominciare da zero, ti basterà evolvere ciò che hai, continuando ad aggiungere funzionalità di alta qualità a una velocità mozzafiato. Devi inoltre assicurarti che ciò che è già presente non funzioni. Come si fa? Fortunatamente, all'interno del settore dell'ingegneria del software si sta formando un nuovo campo che affronta questo scenario comune: in Google, noi chiamiamo questo "test engineering".
Questo discorso si concentra su cos'è l'ingegneria dei test, come si è evoluta dal controllo qualità e in che modo il settore nel suo complesso ha implementato l'ingegneria di test (con esempi specifici di come viene implementata in Google).
Link: Video, Presentazioni
Sistemi di test su larga scala @Twitter
James Waldrop (Twitter)
James parlerà degli strumenti, del processo e della filosofia che caratterizza i test delle prestazioni su Twitter. Verrà data particolare importanza alla libreria di test del carico open source Iago, che ha scritto per consentire ai team di tecnici di Twitter di eseguire test di carico prima di eseguire il deployment del codice in produzione. L'argomento tratta dei dettagli dell'implementazione di alcuni di questi test (incluso il codice sorgente) e della gestione di fattori complicanti come OAuth e i protocolli arbitrari di Thrift.
Link: Video, Presentazioni
Come si testa un sistema operativo per dispositivi mobili?
David Burns (Mozilla) e Malini Das (Mozilla)
Questo è il problema che ha incontrato Mozilla quando abbiamo deciso di avventurarci nel mondo di FirefoxOS. Da dove iniziare e come farlo si è rivelato un'attività interessante. Scopri come abbiamo risolto il problema e come abbiamo creato un nuovo framework.
Link: Video, Presentazioni
Automazione mobile nella pipeline di distribuzione continua
Igor Dorovskikh (Expedia) e Kaustubh Gawande (Expedia)
Expedia ha iniziato a investire in app mobile e app per iOS/Android all'inizio del 2012. Contemporaneamente, gli ingegneri del test hanno iniziato a sviluppare soluzioni di automazione dei test per creare qualità e testabilità nei prodotti sin dall'inizio. In questo intervento, condivideremo la nostra esperienza e la nostra esperienza nell'utilizzo di strumenti open source per creare test automatici nello sviluppo agile e nella distribuzione continua di Expedia. Parleremo di Test Pyramid e esploreremo più nel dettaglio gli strumenti open source specifici che hanno funzionato bene per noi. Alcuni degli strumenti open source che utilizziamo sono strumenti BDD come Cucumber, lo strumento di automazione web Selenium-WebDriver, lo strumento di automazione iOS Frank, gli strumenti di automazione Android Robotium e Calabash e il sistema di integrazione continua Jenkins. Inoltre, condivideremo alcuni dei principi di Agile delivery che adottiamo come TDD, Pair Programming, Build and Test RadiRadis (Accoppiamento della programmazione delle combinazioni, Programmazione e costruzione di radiatori di prova). Infine, condivideremo alcuni dei vantaggi che abbiamo realizzato dal nostro investimento in Agile e nell'automazione dei test e su come questo ci sta raggiungendo i nostri obiettivi di Distribuzione continua.
Link: Video, Presentazioni
Test automatici del decoder con GStreamer e OpenCV
David Röthlisberger (YouView)
Creeremo un sistema di riconoscimento delle immagini di acquisizione video in 3 minuti utilizzando gli strumenti a riga di comando di GStreamer e OpenCV. GStreamer è un framework di gestione di contenuti multimediali open source; OpenCV ("Open Computer Vision") è una libreria di elaborazione di immagini open source.
Un esempio leader di sistema è http://stb-tester.com, uno strumento open source sviluppato presso YouView per automatizzare i test dell'interfaccia utente dei nostri decoder. Descriveremo stb-tester, la flessibilità offerta dai supporti di GStreamer, alcune delle possibilità che si presenta e le sfide future.
Link: Video
Webdriver per Chrome
Ken Kania (Google)
Fin dall'inizio è un browser solo per Windows, Chrome si è ampliato con Mac, Linux, ChromeOS e, più recentemente, con Android e iOS. I test a livello utente delle applicazioni web su queste piattaforme sono stati difficili e hanno richiesto vari approcci di automazione. Questo intervento descrive il lavoro svolto dal team di Chrome per rendere WebDriver disponibile per Chrome su tutte le piattaforme. Sarà incluso un esame tecnico dell'approccio sottostante, ma ci concentreremo su come gli sviluppatori possono utilizzare il nuovo ChromeDriver per scrivere test per le varie piattaforme di Chrome. Verranno trattati anche lo stato attuale del progetto e una roadmap per il futuro.
Link: Video, Presentazioni
Karma - Test runner per JavaScript
Vojta Jina (Google)
Introduzione a Karma, un runner che rende il test delle applicazioni JavaScript in browser reali fluido e piacevole.
Il test non è facoltativo quando si crea un'applicazione JavaScript che deve funzionare su numerosi browser e dispositivi. Tuttavia, l'esecuzione di test in tutti questi ambienti è difficile. Karma trasforma questo compito tipicamente pesante in un gioco da ragazzi. Ti permette di eseguire test JavaScript in browser o dispositivi reali, come il tuo telefono o tablet, direttamente dalla tua finestra di terminale o dal tuo IDE preferito.
Link: Video
Misurazioni automatiche della qualità dei video
Patrik Höglund (Google)
Sì, è possibile testare automaticamente misurazioni complesse e soggettive, come la qualità video. Questa presentazione mostra come abbiamo realizzato un test end-to-end continuo e automatizzato di una videochiamata WebRTC. Analizzeremo la catena degli strumenti in generale e le sfide che abbiamo incontrato durante la nostra costruzione. È la soluzione ideale se vuoi trovare l'ispirazione per far fare un salto di qualità ai tuoi test sui media.
Link: Video, Presentazioni
Quando cattive cose accadono a buone applicazioni...
Mixa minerale (Netflix)
Il boom del mobile e del tablet ha inondato il settore del software con piattaforme di sviluppo delle applicazioni. Lo sviluppo di applicazioni per consumatori su piattaforme informatiche offre agli utenti finali un'esperienza magica. Le società di software per i consumatori cercano di dare il meglio quando sviluppano un'applicazione per queste piattaforme. Tuttavia, la sfida più grande per lo sviluppo di applicazioni inizia solo dopo che le aziende implementano la prima versione dell'applicazione. I consumatori e le società di software vogliono sfruttare al più presto le ultime caratteristiche e funzionalità dello sviluppo con la massima qualità. Questo porta al tasso di abbandono costante in ogni livello dello stack. Noi ingegneri di automazione dell'interfaccia utente creiamo una varietà di sistemi di rilevamento per rilevare i problemi delle applicazioni prima che dopo. In questo intervento, condividerò alcune delle sfide e i successi ottenuti da questo sistema di rilevamento, che hanno contribuito a individuare problemi che esulano dall'intero livello delle applicazioni, ma che hanno comunque influito negativamente sull'esperienza utente.
Link: Video, Presentazioni
Test per giochi educativi e giochi educativi per test
Tao Xie (Università della Carolina del Nord)
Questo intervento presenta Pex4Fun (http://www.pexforfun.com/), che sfrutta la generazione di test automatici per favorire la valutazione automatica in un sistema di programmazione online in grado di scalare fino a centinaia di migliaia di utenti. Fornisce un'esperienza di gioco orientata alla programmazione al di fuori dell'aula formativa, che consente agli utenti di acquisire varie competenze di programmazione e di ingegneria software, comprese le competenze di test come la scrittura di test di unità con parametri. Pex4Fun contribuisce in modo significativo al problema noto della valutazione dei compiti e fornisce un'esperienza di apprendimento divertente basata sul gioco interattivo. Pex4Fun ha ottenuto un'elevata popolarità nella community: da quando è stato rilasciato al pubblico nel giugno 2010, il numero di clic sul pulsante "Ask Pex!" (che indica i tentativi fatti dagli utenti per risolvere i giochi in Pex4Fun) ha raggiunto oltre un milione all'inizio del 2013.
Link: Video, Presentazioni
Discorso di chiusura - In che modo Facebook verifica Facebook su Android
Simon Stewart (Facebook)
Facebook è una delle applicazioni Android più popolari. In questa conversazione, scoprirai che cosa fa Facebook per garantire che ogni release sia la migliore possibile. Parleremo di ogni cosa, dalla gestione del codice agli approcci ai test e fino alla versione sperimentale.
Link: Video, Presentazioni
Apertura del discorso di apertura - JavaScript testabile - Architecting Your Application for Testability
Mark Trostler (Google)
Il codice JavaScript testabile è un processo. Che si tratti di iniziare con uno slate vuoto o con un'applicazione già implementata (o in una fase intermedia), riuscire a testare il codice JavaScript in modo semplice, pulito ed efficace è una funzionalità necessaria. Il codice che non può essere testato verrà riscritto.
Sebbene JavaScript sia unico per la miriade di ambienti in cui viene eseguito, esistono diverse metodologie "testabili" comprovate da altri linguaggi, che rimangono valide anche per JavaScript. Naturalmente rimangono le sfide uniche che gli sviluppatori JavaScript devono affrontare durante la scrittura e il test del loro codice.
Quali pattern rendono il codice verificabile? Quali test anti-pattern ostacolano il test? Quali metriche e linee guida del buon senso si possono usare per misurare la verificabilità del nostro codice? Una volta iniziato il processo di creazione del codice testabile, adesso?
Unisciti a me per suddividere il processo di scrittura di codice JavaScript testabile. Indagheremo su idee, pattern e metodologie che aumentano notevolmente la capacità di testabilità, quindi la manutenibilità, la correttezza e la longevità del codice. Indipendentemente dal fatto che tu scriva il mastering JavaScript lato client o lato server, la qualità del codice sarà notevolmente migliorata.
Link: Video, Presentazioni
Breaking the Matrix - Test di Android su larga scala
Thomas Knych (Google), Stefan Ramsauer (Google) e Valera Zakharov (Google)
Vuoi prendere la pillola rossa?
I dispositivi mobili hanno cambiato il modo in cui le persone interagiscono con i computer. È una cosa meravigliosa, ma in qualità di ingegneri siamo di fronte a una matrice in continua espansione di ambienti su cui viene eseguito il nostro codice. I giorni in cui prendere in considerazione solo una manciata di browser e risoluzioni dello schermo non tornano. In che modo gli ingegneri possono far fronte a Matrix? Parleremo di come Google sta combattendo questo problema di test sulle workstation, nel cloud e nella tua testa...
"Sto cercando di liberare la mente, Neo. Ma posso mostrarti solo la porta. Sei tu quella che deve attraversarlo."
Link: Video, Presentazioni
Automazione UI Android
Guang Zhu (朱光) (Google) e Adam Momtaz (Google)
Con la crescente popolarità di Android nel mondo dei dispositivi mobili, gli sviluppatori di applicazioni e i fornitori OEM stanno esplorando nuovi modi per eseguire test end-to-end basati sull'interfaccia utente su applicazioni o sull'intera piattaforma. Con una breve revisione delle soluzioni di automazione dell'interfaccia utente esistenti su Android, in questa presentazione viene presentato il framework Automator dell'interfaccia utente di Android rilasciato di recente che continua a fornire un aspetto interno del framework, dei casi d'uso tipici e dei flussi di lavoro.
Link: Video, Presentazioni
Appium: automazione per le app mobile
Jonathan Lipps (Sauce Labs)
Appium è un server Node.js che automatizza le applicazioni mobili native e ibride (sia iOS che Android). La filosofia di Appium impone che le app non debbano essere modificate per poter essere automatizzate e che tu debba scrivere il codice del test in qualsiasi linguaggio o framework. Il risultato è un server Selenium WebDriver che parla dispositivi mobili come gli annunci nativi. Appium viene eseguito su dispositivi e emulatori reali ed è completamente open source, il che lo rende un modo meraviglioso per iniziare a utilizzare l'automazione dei test su dispositivi mobili. In questo intervento, illustrerò i principi alla base della progettazione di Appium, parlerò di Appium nello spazio di altri framework di automazione mobile e presenterò l'architettura che rende possibile la magia. Infine, analizza il codice per un semplice test di una nuova app mobile e dimostrerò che Appium esegue questo test su iPhone e Android.
Link: Video, Presentazioni
Creare un'infrastruttura di test mobile scalabile per Google+ Mobile
Eduardo Bravo (Google)
Testare le app native in modo significativo, stabile e scalabile è una sfida. G+ ha sviluppato soluzioni efficienti per affrontare questi problemi, fornendo l'infrastruttura adatta a ciascuno dei complessi scenari di test presentati dai dispositivi mobili. La nostra attuale infrastruttura di test fornisce gli strumenti giusti alle app per iOS e Android per garantire al nostro team di sviluppo la certezza che le nuove modifiche non danneggeranno i clienti esistenti.
Link: Video, Presentazioni
Espresso: nuovo test della UI per Android
Valera Zakharov (Google)
Aggiornamento [ottobre 2013]: Espresso è ora open source. Consulta https://code.google.com/p/android-test-kit/.
Sviluppare un test Android affidabile dovrebbe essere facile e veloce quanto preparare un caffè. Sfortunatamente, con gli strumenti esistenti, potrebbe essere più come fare una salsa a doppia caramello, ma anche del latte macchiato-frullante, confondendo e raramente coerente. Espresso è un nuovo framework di test per Android che ti consente di scrivere rapidamente test dell'interfaccia utente concisi, belli e affidabili. L'API principale è piccola, prevedibile e facile da imparare, ma è anche aperta per la personalizzazione. I test Espresso indicano chiaramente le aspettative, le interazioni e le affermazioni senza distrarre la caldaia, l'infrastruttura personalizzata o i fastidiosi dettagli di implementazione. I test vengono eseguiti in modo ottimale: lascia indietro le attese, le sincronizzazioni, il sonno e i sondaggi e lascia che il framework manipoli e dichiari elegantemente la tua UI quando è at-rest. Inizia a scrivere ed eseguire test dell'interfaccia utente: prova una foto di Espresso.
Link: Video, Presentazioni
Test delle prestazioni web con WebDriver
Michael Klepikov (Google)
Nei test del rendimento sul Web, sappiamo come analizzare un caricamento pagina. Dobbiamo andare oltre il caricamento di una pagina: le app moderne sono altamente interattive e le operazioni tendono a non ricaricare l'intera pagina, ma piuttosto ad aggiornarla. Diverse persone, incluso me, hanno integrato WebDriver nelle imbracature per i test delle prestazioni web, il che aiuta, ma mantiene comunque separati i test sulle prestazioni dalle altre suite di test dell'interfaccia utente. Provo a integrare le funzionalità di test delle prestazioni direttamente in WebDriver, sfruttando l'API Logging aggiunta di recente. In questo modo è possibile raccogliere metriche sul rendimento durante l'esecuzione di normali test funzionali, consentendo un'integrazione molto più fluida dei test sul rendimento nell'intero flusso di sviluppo e test. È inoltre molto meno invasivo per le catene di strumenti di test/build personalizzate create da quasi tutte le grandi organizzazioni.
Te lo dimostrerò con ChromeDriver (WebDriver per il browser Chromium) di nuova generazione.
Link: Video, Presentazioni
Test continuo di dati di Maps
Yvette Nameth (Google) e Brendan Dhein (Google)
In genere, il test continuo riguarda l'esecuzione di test delle unità e dei test di integrazione. Se però i dati elaborati dal tuo server sono la principale causa di cambiamento, come puoi assicurarti che i consumatori dei dati li trovino ancora utilizzabili e che nulla si arresti sotto la frequenza o un cambiamento negativo? Parleremo di tecniche per il test continuo dei dati con esempi di Google Maps.
Link: Video, Presentazioni
Ricerca automatica delle colpevoli in errore nelle build, ad esempio Chi ha rotto la build?
Celal Ziftci (UCSD) e Vivek Ramavajjala (Google)
La build continua è una delle infrastrutture chiave di Google. Quando una build non va a buon fine, è fondamentale individuare rapidamente l'elenco di modifiche (CL) o gli elenchi di modifiche del colpevole, in modo che possa essere risolto in modo che diventi di nuovo verde.
Esistono soluzioni di rilevamento delle colpe per piccole e medie dimensioni, ma non per grandi build di integrazione.
Il nostro responsabile per la ricerca dei colpevoli mira a trovare il colpevole CL per grandi build automaticamente, in un lasso di tempo molto breve e con un alto successo. In base all'utilizzo della produzione su più progetti negli ultimi 9 mesi, la ricerca dei colpevoli fornisce risultati molto promettenti. Segui il nostro discorso per scoprire come abbiamo implementato il rilevatore di colpa, il suo successo in produzione e l'aspetto e il funzionamento.
Link: Video, Presentazioni
Indagine empirica sulla qualità delle linee di prodotti software
Katerina Goseva-Popstojanova (West Virginia University)
Le linee di prodotti software mostrano un elevato grado di accomunanza tra i sistemi della linea di prodotti e un numero ben specificato di possibili varianti. Sulla base dei dati estratti da due case study, una linea di prodotti industriali di medie dimensioni e una linea di prodotti open source ampia e in evoluzione, abbiamo esplorato empiricamente se il riutilizzo sistematico migliora la qualità e supporta la previsione di potenziali errori futuri da errori riscontrati in precedenza, metriche del codice sorgente e metriche di variazione. I risultati della nostra ricerca hanno confermato, nell'ambito di un'impostazione della linea di prodotti software, i risultati di altri che i guasti sono più strettamente correlati alla modifica delle metriche che a quelle del codice statico. I risultati della valutazione della qualità hanno mostrato che, sebbene i pacchetti meno recenti (comuni comuni) cambiassero continuamente, contenevano una bassa densità di errore. Inoltre, la linea di prodotti open source ha migliorato la qualità di pari passo con l'evoluzione delle release. La previsione basata sui modelli di regressione lineare generalizzati ha classificato accuratamente i pacchetti in base agli errori post-release utilizzando i modelli creati sulla release precedente. I risultati hanno anche rivelato che le previsioni di errore post-release sfruttano le informazioni aggiuntive sulla linea di prodotti.
Link: Video, Presentazioni
IndirizzoSanitizer, ThreadSanitizer e MemorySanitizer - Strumenti di test dinamici per C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) è uno strumento che trova overflow del buffer (in stack, heap e globali) e bug use-after-free nei programmi C/C++. ThreadSanitizer (TSan) trova gare con i dati nei programmi C/C++ e Go. MemorySanitizer (MSan) è uno strumento di lavoro in corso che trova l'uso di memoria non inizializzata (C++). Questi strumenti si basano sulla strumentazione di compilazione (LLVM e GCC), il che li rende molto veloci (ad esempio, ASan ha solo il doppio del rallentamento). Condivideremo la nostra esperienza in test su larga scala utilizzando questi strumenti.
Link: Video, Presentazioni
Discorso di chiusura - Bere l'oceano - Alla ricerca degli XSS su scala Google
Claudio Criscione (Google)
Il cross-site scripting (XSS) è l'equivalente moderno della peste nera di epoca medievale nel mondo delle applicazioni web: è diffuso, è negativo e ci sono pochi modi o nessun metodo tecnico per individuarlo fino a quando non è troppo tardi. DOM XSS è una variante particolarmente fastidiosa, in quanto richiede un browser reale o un equivalente per essere rilevato: un problema difficile con scarsa soluzione automatizzata disponibile.
Avevamo bisogno di strumenti potenti e autogestinti per identificare DOM XSS all'inizio del ciclo di vita dello sviluppo, utilizzabili da ingegneri esterni al team di sicurezza: tutto quello che volevamo era un prodotto in grado di scansionare il nostro enorme corpus di applicazioni, in movimento, altamente complesso e arcano... e, naturalmente, non ne abbiamo trovato nessuno. Ecco perché abbiamo creato il nostro: uno scanner di applicazioni web che ha come target DOM XSS e progettato in base alle tecnologie Google standard. Viene eseguito in App Engine e sfrutta il potente browser Chrome e alcune centinaia di CPU come piattaforma di analisi della sicurezza.
È anche un buon cittadino dell'arsenale di test di Google: vive all'interno della nostra infrastruttura di test, invece di essere lo strumento del team di sicurezza.
In questo intervento illustreremo il nostro nuovo approccio, le sfide che abbiamo affrontato per scalare il nostro sistema alle dimensioni di Google e le idee alla base dei nostri modelli di rilevamento e scansione per le applicazioni ad alta intensità di JavaScript.
Link: Video, Presentazioni