Membuka Keynote - JavaScript yang Dapat Diuji - Merancang Aplikasi Anda untuk Kemampuan Pengujian
Mark Trostler (Google)
JavaScript yang dapat diuji adalah suatu proses. Mulai dari layar kosong atau aplikasi yang sudah diimplementasikan (atau di antara keduanya) dapat menguji kode JavaScript Anda dengan sederhana, bersih, dan efektif adalah fitur yang diperlukan. Kode yang tidak dapat diuji akan ditulis ulang.
Meskipun JavaScript bersifat unik karena berbagai lingkungan tempatnya berjalan, ada beberapa metodologi 'yang dapat diuji' yang telah teruji dari bahasa lain yang juga berlaku untuk JavaScript. Dan tentu saja, ada tantangan unik yang harus dihadapi developer JavaScript saat menulis dan menguji kode mereka.
Pola apa yang membuat kode dapat diuji? Anti-pola mana yang menghambat pengujian? Metrik dan postingan panduan umum apa yang dapat digunakan untuk mengukur kemampuan pengujian kode kami? Setelah proses pembuatan kode yang dapat diuji dimulai sekarang, apa langkah selanjutnya?
Bergabunglah dengan kami untuk membahas proses penulisan JavaScript yang dapat diuji. Kami akan menyelidiki ide, pola, dan metodologi yang sangat meningkatkan kemampuan pengujian, dan karenanya mempertahankan pemeliharaan, ketepatan, dan lama kode Anda. Apakah Anda menulis master JavaScript sisi klien atau server, proses ini akan sangat meningkatkan kualitas kode.
Breaking the Matrix - Pengujian Android dalam Skala
Thomas Knych (Google), Stefan Ramsauer (Google), dan Valera Zakharov (Google)
Anda siap minum pil merah?
Perangkat seluler telah mengubah cara manusia berinteraksi dengan komputer. Ini bagus, tetapi sebagai engineer, kami dihadapkan dengan matriks lingkungan yang terus berkembang tempat kode kami berjalan. Hari-hari dengan mempertimbangkan hanya sedikit browser dan resolusi layar yang tidak akan kembali. Bagaimana cara engineer mengatasi Matriks? Kita akan membahas cara Google menghadapi masalah pengujian ini di workstation, cloud, dan head...
"Saya mencoba membebaskan pikiran Anda, Neo. Tapi saya hanya bisa tunjukkan pintunya. Hanya Anda yang harus melewatinya".
Otomatisasi UI Android
Guang Zhu (朱光) (Google) dan Adam Momtaz (Google)
Karena Android semakin populer di dunia seluler, developer aplikasi dan vendor OEM menjelajahi berbagai cara untuk melakukan pengujian aplikasi UI secara menyeluruh atau di seluruh platform. Dengan tinjauan singkat tentang solusi Otomatisasi UI yang ada di Android, pembahasan ini memperkenalkan framework UI Automator Android yang baru dirilis, dan terus memberikan penjelasan tentang framework, kasus penggunaan, dan alur kerja umum.
Appium: Otomatisasi untuk Aplikasi Seluler
Jonathan Lipps (Saus Lab)
Appium adalah server Node.js yang mengotomatiskan aplikasi seluler native dan hybrid (baik iOS maupun Android). Filosofi Appium menyatakan bahwa aplikasi tidak boleh diubah agar menjadi otomatis, dan Anda harus dapat menulis kode pengujian dalam bahasa atau framework apa pun. Hasilnya adalah server Selenium WebDriver yang berbicara seluler seperti native. Appium berjalan di perangkat dan emulator sungguhan dan merupakan open source sepenuhnya, menjadikannya cara yang sangat cocok untuk memulai otomatisasi pengujian seluler. Dalam pembahasan ini, saya akan menguraikan prinsip-prinsip yang mendasari desain Appium, membahas Appium dalam bidang framework otomatisasi seluler lainnya, dan memperkenalkan arsitektur yang menciptakan keajaiban. Terakhir, saya akan menggali kode untuk pengujian sederhana aplikasi seluler baru, dan menunjukkan Appium yang menjalankan pengujian ini di iPhone dan Android.
Membangun Infrastruktur Uji Seluler yang Skalabel untuk Google+ Seluler
Eduardo Bravo (Google)
Menguji aplikasi native dengan cara yang bermakna, stabil, dan skalabel merupakan tantangan. G+ telah mengembangkan solusi yang efisien untuk mengatasi masalah ini dengan menyediakan infrastruktur yang tepat untuk setiap skenario pengujian kompleks yang disajikan oleh seluler. Infrastruktur pengujian kami saat ini menyediakan alat yang tepat untuk aplikasi iOS dan Android guna memberi keyakinan kepada tim pengembangan kami bahwa perubahan baru tidak akan mengganggu klien yang ada.
Espresso: Pengujian UI baru untuk Android
Valera Zakharov (Google)
Mengembangkan pengujian Android yang andal harus semudah dan semudah mengambil gambar espresso. Sayangnya, dengan alat yang ada, alat ini mungkin terasa lebih seperti double-shot-caramel-flavor-upside-down-single-whip-half-decaf-latte karena membingungkan dan jarang konsisten. Espresso adalah framework pengujian Android baru yang memungkinkan Anda menulis pengujian UI yang ringkas, menarik, dan andal dengan cepat. API inti berukuran kecil, dapat diprediksi, dan mudah dipelajari. Namun, API ini juga dapat disesuaikan. Pengujian Espresso menyatakan ekspektasi, interaksi, dan pernyataan mereka dengan jelas tanpa mengganggu boilerplate, infrastruktur kustom, atau detail implementasi yang berantakan. Pengujian berjalan optimal dengan cepat - tunggu, sinkronkan, tidur, dan lakukan polling, lalu biarkan framework memanipulasi dan menyatakan dengan lancar ketika UI sedang dalam keadaan nonaktif. Mulailah menikmati menulis dan mengeksekusi pengujian UI - cobalah suntikan Espresso.
Pengujian Performa Web dengan WebDriver
Michael Klepikov (Google)
Dalam pengujian performa web, kita tahu betul cara menganalisis pemuatan halaman. Namun, kami perlu beralih di luar pemuatan halaman: aplikasi modern sangat interaktif, dan operasinya cenderung tidak memuat ulang seluruh halaman, melainkan memperbaruinya. Orang yang berbeda, termasuk saya, telah mengintegrasikan WebDriver ke dalam rangkaian pengujian performa web, yang membantu, tetapi tetap memisahkan pengujian performa dari rangkaian pengujian UI lainnya. Saya mengusulkan untuk mem-build fitur pengujian performa langsung ke WebDriver sendiri, memanfaatkan Logging API yang baru-baru ini ditambahkan. Hal ini memungkinkan pengumpulan metrik performa saat menjalankan pengujian fungsional reguler, sehingga integrasi pengujian performa menjadi jauh lebih lancar ke dalam alur pengembangan dan pengujian secara keseluruhan. Ini juga jauh lebih tidak mengganggu toolchain/build pengujian kustom yang dibuat oleh hampir setiap organisasi besar.
Kami akan mendemonstrasikan hal ini dengan ChromeDriver generasi baru (WebDriver untuk browser Chromium).
Pengujian Data Maps Berkelanjutan
Yvette Nameth (Google) dan Brendan Dhein (Google)
Pengujian berkelanjutan umumnya adalah menjalankan pengujian unit dan pengujian integrasi. Namun, saat data yang diproses server Anda sebenarnya adalah penyebab perubahan terbesar, bagaimana Anda memastikan bahwa konsumen data masih dapat digunakan dan tidak ada yang error di bawah laju perubahan atau perubahan yang buruk? Kita akan membahas teknik untuk pengujian data berkelanjutan dengan contoh dari Google Maps.
Menemukan Culprit Secara Otomatis di Build yang Gagal - yaitu Siapa yang Rusak Build-nya?
Celal Ziftci (UCSD) dan Vivek Ramavajjala (UCSD)
Build berkelanjutan adalah salah satu infrastruktur utama di Google. Jika build gagal, penting untuk menentukan daftar perubahan penyebab (CL)/daftar perubahan dengan cepat, sehingga dapat diperbaiki agar build kembali berwarna hijau.
Solusi deteksi kulprit ada untuk build kecil dan menengah, tetapi tidak untuk build integrasi besar.
Pencari penyebab kami menargetkan menemukan CL penyebab masalah untuk build besar secara otomatis, dalam jangka waktu yang sangat singkat dengan kesuksesan tinggi. Berdasarkan penggunaan produksi pada beberapa project dalam 9 bulan terakhir, pencari pencari memberikan hasil yang sangat menjanjikan. Lihat diskusi kami untuk melihat cara kami menerapkan pencari penyebab, seberapa suksesnya dalam produksi, serta seperti apa rasanya dan seperti apa tampilannya.
Investigasi Empiris terhadap Kualitas Lini Produk Software
Katerina Goseva-Popstojanova (West Virginia University)
Lini produk software menunjukkan kesamaan yang tinggi di antara sistem dalam lini produk dan jumlah kemungkinan variasi yang ditentukan. Berdasarkan data yang diekstrak dari dua studi kasus - lini produk industri ukuran sedang dan lini produk open source yang besar dan terus berkembang - kami mengeksplorasi secara empiris jika penggunaan kembali yang sistematis meningkatkan kualitas dan mendukung prediksi potensi kesalahan di masa mendatang dari kesalahan yang dialami sebelumnya, metrik kode sumber, dan perubahan metrik. Hasil riset kami mengonfirmasi, dalam setelan lini produk software, temuan pihak lain bahwa kesalahan lebih berkorelasi dengan perubahan metrik dibandingkan dengan metrik kode statis. Hasil penilaian kualitas menunjukkan bahwa meskipun paket yang lebih lama (termasuk kesamaan), terus berubah, sehingga kepadatan tetap rendah. Selain itu, kualitas lini produk open source meningkat seiring berkembangnya rilis. Prediksi berdasarkan model regresi linier umum secara akurat memberikan peringkat pada paket sesuai dengan kesalahan pasca-rilis menggunakan model yang dibuat pada rilis sebelumnya. Hasilnya juga mengungkapkan bahwa prediksi kesalahan pasca-rilis memanfaatkan informasi lini produk tambahan.
AddressSanitizer, ThreadSanitizer, dan MemorySanitizer -- Alat Pengujian Dinamis untuk C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) adalah alat yang menemukan overflow buffering (dalam stack, heap, dan global) serta bug penggunaan setelah memori dalam program C/C++. ThreadSanitizer (TSan) menemukan data race dalam program C/C++ dan Go. MemorySanitizer (MSan) adalah alat yang sedang berlangsung yang menemukan penggunaan memori yang tidak diinisialisasi (C++). Alat ini didasarkan pada instrumentasi compiler (LLVM dan GCC), yang membuatnya sangat cepat (misalnya ASan hanya menimbulkan 2x pelambatan). Kami akan membagikan pengalaman dalam pengujian berskala besar menggunakan alat-alat ini.
Keynote Penutup - Minum Lautan - Menemukan XSS dalam Skala Google
Claudio Criscione (Google)
Pembuatan skrip lintas situs, atau XSS, setara dengan wabah hitam abad pertengahan yang modern di dunia aplikasi web: penyebarannya luas, buruk, dan hanya ada sedikit atau tidak ada cara teknis untuk mendeteksinya hingga terlambat. DOM XSS adalah varian yang sangat menjijikkan dari keduanya, karena memerlukan browser sungguhan atau yang setara untuk dideteksi: masalah sulit dengan sedikit solusi otomatis yang tersedia.
Kami membutuhkan alat mandiri yang canggih untuk mengidentifikasi DOM XSS di awal siklus proses pengembangan, yang dapat digunakan oleh para engineer di luar tim keamanan: kami hanya ingin produk yang dapat memindai kumpulan aplikasi kami yang besar, bergerak cepat, sangat kompleks, dan sulit ditemukan. Tentu saja, kami tidak menemukan apa pun. Jadi, kami membuat sendiri: pemindai aplikasi web yang menargetkan DOM XSS yang dirancang dengan teknologi Google standar. Cloud Run berjalan di App Engine dan memanfaatkan browser Chrome yang kuat dan beberapa CPU sebagai platform pemindaian keamanan.
Mereka juga merupakan warga yang baik dari persenjataan pengujian di Google: lembaga ini berada di dalam infrastruktur pengujian kami, bukan menjadi instrumen tim keamanan.
Dalam pembahasan ini, kami menguraikan pendekatan baru kami, tantangan yang kami hadapi saat menskalakan sistem kami ke ukuran Google, serta ide di balik model deteksi dan crawling kami pada aplikasi yang intensif JavaScript.