Açılış Konuşması - Test Edilebilir JavaScript - Uygulamanızı Test Edilebilirlik için Mimarileme
Mark Trostler (Google)
Test edilebilir JavaScript bir işlemdir. Boş bir listeden veya halihazırda uygulanmış bir uygulamadan (ya da bu ikisi arasında bir yerden) başlamak, JavaScript kodunuzu basit, temiz ve etkili bir şekilde test edebilmenizi sağlayan bir özelliktir. Test edilemeyen kod yeniden yazılır.
JavaScript, çalıştığı çok sayıda ortam nedeniyle benzersiz olsa da, diğer dillerden JavaScript için de geçerli olan birkaç denenmiş ve gerçek "test edilebilir" metodoloji vardır. Elbette, JavaScript geliştiricilerinin kodlarını yazıp test ederken karşılaşmaları gereken benzersiz zorluklar devam etmektedir.
Kodu hangi cihazlarda test edebilirsiniz? Desenleri engelleyen testler hangileri? Kodumuzun test edilebilirliğini ölçmek için hangi metrikler ve sağduyu yönergeleri kullanılabilir? Test edilebilir kod oluşturma işlemi başladığında ne olur?
Test edilebilir JavaScript yazma işleminin dökümünü almak için bana katılın. Test edilebilirliği ve dolayısıyla kodunuzun sürdürülebilirliğini, doğruluğunu ve ömrünü büyük ölçüde artıran fikirleri, kalıpları ve metodolojileri araştıracağız. Bu işlemde uzmanlaşmış istemci veya sunucu tarafı JavaScript yazdığınızda kodunuzun kalitesi büyük ölçüde artar.
Breaking the Matris - Android Testi Geniş Ölçekte
Thomas Knych (Google), Stefan Ramsauer (Google) ve Valera Zakharov (Google)
Kırmızı hapı almaya hazır mısın?
Mobil cihazlar, kullanıcıların bilgisayarlarla etkileşim şeklini değiştirdi. Bu harika bir şey, ancak mühendisler olarak kodumuzun sürekli olarak değiştiği bir ortam matrisi ile karşı karşıyayız. Yalnızca birkaç tarayıcıyı ve ekran çözünürlüğünü göz önünde bulundurduğumuz günler geri dönmüyor. Mühendisler Matris ile nasıl başa çıkabilir? Google'ın iş istasyonlarında, bulutta ve kafanızda bu test sorunuyla nasıl mücadele ettiğini ele alacağız...
"Aklını serbest bırakayım Neo. Ama sana sadece kapıyı gösterebilirim. Onunla başa çıkması gerekiyor."
Android Kullanıcı Arayüzü Otomasyonu
Guang Zhu (朱光) (Google) ve Adam Momtaz (Google)
Android, mobil dünyada popülerlik kazanırken, uygulama geliştiricileri ve OEM satıcıları, uygulamalar veya platform genelinde kullanıcı arayüzü üzerinden uçtan uca testlerin yöntemlerini araştırıyor. Android'deki mevcut kullanıcı arayüzü otomasyon çözümlerinin kısa bir incelemesi sonucunda bu konuşma, kısa süre önce kullanıma sunulan Android kullanıcı arayüzü otomasyonu çerçevesini tanıtıyor. Ayrıca çerçeve, tipik kullanım alanları ve iş akışları hakkında bilgi vermeye devam ediyor.
Appium: Mobil Uygulamalar için Otomasyon
Jonathan Lipps (Sos Labs)
Appium, yerel ve karma mobil uygulamaları (iOS ve Android) otomatikleştiren bir Node.js sunucusudur. Appium'un felsefesine göre, uygulamaların otomatik olması için değiştirilmemesi gerekir. Test kodunuzu herhangi bir dilde veya çerçevede yazabilirsiniz. Bunun sonucunda, mobil ana dili gibi bir Selenium WebDriver sunucusu olur. Gerçek cihazlar ve emülatörlerde çalışan Appium, mobil test otomasyonunu kullanmaya başlamanın harika bir yolu olan tamamen açık kaynaklı. Bu konuşmada, Appium'un tasarımına yön veren ilkeleri açıklayacak, diğer mobil otomasyon çerçeveleri alanında Appium'dan bahsedecek ve sihri gerçekleştiren mimariyi tanıtacağım. Son olarak, yeni bir mobil uygulamanın basit bir testini yapmak için kodu inceleyeceğim ve Appium'un bu testi iPhone ve Android'de çalıştırdığını göstereceğim.
Google+ Mobil İçin Ölçeklenebilir Mobil Test Altyapısı Oluşturma
Eduardo Bravo (Google)
Yerel uygulamaları anlamlı, kararlı ve ölçeklenebilir bir şekilde test etmek zordur. G+, mobil cihazların sunduğu karmaşık test senaryolarının her biri için doğru altyapıyı sağlayarak bu tür sorunları ele almaya yönelik etkili çözümler geliştirmiştir. Mevcut test altyapımız, hem iOS hem de Android uygulamaları için doğru araçları sağlayarak geliştirme ekibimize, yeni değişikliklerin mevcut müşterileri olumsuz etkileme ihtimalini azaltmaktadır.
Espresso: Android Kullanıcı Arayüzü Testine Yeni Başlama
Valera Zakharov (Google)
Güvenilir bir Android testi geliştirmek espresso çekmek kadar hızlı ve kolay olmalıdır. Ne yazık ki mevcut araçlarda çift çekimli-karamel-sos-yukarı-aşağı-tek-çırpıcı-yarım-kahverengi-kahverengi tonların kullanılması gibi bir fikirle karşılaşabilirsiniz. Espresso kısa, öz, güzel ve güvenilir kullanıcı arayüzü testleri yazmanıza olanak sağlayan yeni bir Android test çerçevesidir. Temel API küçük, öngörülebilir ve kolayca öğrenilebilir, ancak özelleştirmeye de açıktır. Espresso testleri; dikkat çeken ortak noktalar, özel altyapılar veya karmaşık uygulama ayrıntılarının önüne geçmeden beklentilerini, etkileşimlerini ve iddialarını açıkça belirtiyor. Testler optimum hızda çalışır. Beklemeleriniz, senkronizasyonlarınız, uykularınız ve anketlerinizi geride bırakmayın. Ayrıca çerçeve, aktif olmayan kullanıcı arayüzünü sorunsuz şekilde manipüle edip onlar adına yorum yapsın. Kullanıcı arayüzü testlerini yazmayı ve yürütmenin keyfini çıkarmaya başlayın. Espresso'yu çekmeyi deneyin.
WebDriver ile Web Performansı Testi
Michael Klepikov (Google)
Web performansı testinde, bir sayfa yüklemesinin nasıl analiz edileceğini oldukça iyi biliyoruz. Yine de bir sayfa yüklemesinin ötesine geçmemiz gerekiyor: Modern uygulamalar oldukça etkileşimlidir ve işlemler sayfanın tamamını yeniden yükleme eğiliminde olmak yerine sayfayı günceller. Kendim de dahil olmak üzere farklı kişiler, WebDriver'ı web performansı test donanımına entegre etti, ancak bu yöntem, performans testlerini kullanıcı arayüzü test paketinin geri kalanından ayrı tutar. Yakın zamanda eklenen Logging API'den yararlanarak performans testi özelliklerini doğrudan WebDriver'da oluşturmayı öneriyorum. Bu sayede, düzenli olarak gerçekleştirilen işlevsel testler yürütürken performans metrikleri toplanabilir. Böylece, performans testlerinin genel geliştirme ve test akışına çok daha sorunsuz bir şekilde entegre edilmesi sağlanır. Ayrıca, neredeyse her büyük kuruluşun oluşturduğu özel derleme/test araç zincirlerinde çok daha az kesintiye uğrar.
Bunu yeni nesil ChromeDriver (Chromium tarayıcısı için WebDriver) ile göstereceğim.
Sürekli Haritalar Veri Testi
Yvette Nameth (Google) ve Brendan Dhein (Google)
Sürekli test, genellikle birim testleri ve entegrasyon testleri çalıştırmayla ilgilidir. Peki, sunucunuzun işleme koyduğu veriler değişimin en büyük nedeniyse, bu verileri kullanan tüketicilerin verileri hâlâ yararlı bulmalarını ve değişim hızı veya kötü bir değişimin altında hiçbir şeyin kilitlenmemesini nasıl sağlayabilirsiniz? Google Haritalar'daki örneklerle sürekli veri testi tekniklerinden bahsedeceğiz.
Başarısız Yapılarda Suçluları Otomatik Olarak Bulma - Kimler Yapıyı Bozuyor?
Celal Ziftci (UCSD) ve Vivek Ramavajjala (UCSD)
Sürekli derleme, Google'ın temel altyapılarından biridir. Bir derleme başarısız olduğunda, bunun sorumlusu (CL)/değişiklik listelerinin hızlı bir şekilde belirlenmesi çok önemlidir. Böylece, yapı tekrar yeşile dönebilir.
Sorun algılama çözümleri küçük ve orta ölçekli derlemeler için mevcuttur ancak büyük entegrasyon derlemeleri için kullanılamaz.
Sorun bulma aracımız, büyük derlemeler için suçlu CL'yi otomatik olarak ve kısa bir süre içinde ve başarılı bir şekilde bulmayı hedefler. Son 9 ayda birçok projede prodüksiyon kullanımını temel alan suçlu bulma aracı, gelecek vaat eden sonuçlar sunar. Bu suçlunun nasıl tespit edildiğini, üretimde ne kadar başarılı olduğunu ve neye benzediğini görmek için konuşmamıza göz atın.
Yazılım Ürün Grubu Kalitesinin Denetlenmesi
Katerina Goseva-Popstojanova (Batı Virginia Üniversitesi)
Yazılım ürün hatları, ürün serisindeki sistemler arasında yüksek düzeyde ortak çalışmalar ve iyi tanımlanmış belirli bir varyasyon sayısını gösterir. Orta büyüklükteki bir sanayi ürünü ve büyük, gelişen bir açık kaynak ürün serisinden alınan iki örnek olaydan elde edilen verilere dayanarak, sistematik yeniden kullanımın kaliteyi iyileştirdiğini ve daha önce karşılaşılan hatalardan, kaynak kodu metriklerinden ve değişiklik metriklerinden gelecekte meydana gelebilecek hataların başarılı bir şekilde tahmin edilmesini desteklediğini gözlemleyerek araştırdık. Araştırma sonuçlarımız, bir yazılım ürün serisi ayarında, hatalı diğer deneme bulgularının değişim metrikleriyle statik kod metriklerine kıyasla çok daha fazla ilişkili olduğunu gösteriyor. Kalite değerlendirme sonuçları, ortak paketlerin de dahil olduğu eski paketlerin sürekli olarak değişse de düşük hata yoğunluklarını koruduklarını gösteriyor. Ayrıca, açık kaynak ürün grubu, sürümler geliştirdikçe kaliteyi artırdı. Genelleştirilmiş doğrusal regresyon modellerine dayalı tahmin, önceki sürümde oluşturulan modelleri kullanarak paketleri yayın sonrası hatalarına göre doğru şekilde sıraladı. Sonuçlar, yayın sonrası hata tahminlerinin ek ürün serisi bilgilerinden yararlandığını da gösterdi.
AddressSanitizer, ThreadSanitizer ve BellekSanitizer -- C++ için Dinamik Test Araçları
Kostya Serebryany (Google)
AddressSanitizer (ASan), C/C++ programlarında arabellek taşması (yığın, yığın ve genel olarak) ve boşaltıldıktan sonra kullanım hatalarını bulan bir araçtır. ThreadSanitizer (TSan), C/C++ ve Go programlarındaki veri yarışlarını bulur. BellekSanitizer (MSan), başlatılmamış belleğin (C++) kullanımlarını bulan, devam eden bir araçtır. Bu araçlar, derleyici araçlarına (LLVM ve GCC) dayanır, bu da onları çok hızlı hale getirir (örneğin, ASan yalnızca 2 kat daha fazla yavaşlamaya neden olur). Bu araçları kullanarak büyük ölçekli testlerle ilgili deneyimimizi paylaşacağız.
Açılış Konuşması - Okyanusun İçecekleri - Google ölçeğinde XSS bulma
Claudio Criscione (Google)
Siteler arası komut dosyası çalıştırma olan XSS, web uygulaması dünyasında orta çağda siyahiler için uygulanan eşdeğerdir: Yaygındır, kötüdür ve çok geç olana kadar tespit edilmesi için çok az teknik yöntem bulunmaktadır veya hiç yoktur. DOM XSS, çok kötü bir alternatiftir çünkü gerçek bir tarayıcının veya eşdeğerinin algılanması gerektirir: Çok az otomatik çözümle zor bir sorun.
DOM XSS'yi geliştirme döngüsünün başlarında tanımlamak için güçlü ve kendi kendine çalışan araçlara ihtiyacımız vardı. Bu özellikler, güvenlik ekibinin dışındaki mühendisler tarafından kullanılabiliyordu: Tek yapmamız gereken büyük, hızlı, son derece karmaşık ve arkettik uygulama derlemelerimizi tarayabilen ürünlerdi ve elbette hiçbir şeyi bulamadık. Bu yüzden, standart Google teknolojilerine dayanarak tasarlanmış, DOM XSS'yi hedefleyen bir web uygulaması tarayıcısı geliştirdik. App Engine'de çalışır ve güçlü Chrome tarayıcısından ve yüzlerce CPU'dan güvenlik tarama platformu olarak yararlanır.
Ayrıca Google'ın test cephaneliğinin güzel bir vatandaşı: Güvenlik ekibinin enstrümanı yerine test altyapımızın içinde yaşıyor.
Bu konuşmada, yeni yaklaşımımızı, sistemimizi Google'ın boyutuna göre ölçeklendirme konusunda karşılaştığımız güçlüklerin yanı sıra JavaScript'i yoğun olarak kullanan uygulamalardaki algılama ve tarama modellerimizin arkasındaki fikirleri özetliyoruz.