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.
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."
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.
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.
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.
Espresso: nuovo test della UI per Android
Valera Zakharov (Google)
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.
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.
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.
Ricerca automatica delle colpevoli in errore nelle build, ad esempio Chi ha rotto la build?
Celal Ziftci (UCSD) e Vivek Ramavajjala (UCSD)
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.
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.
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.
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.