Açılış Konuşmaları
Tony Voellm (Google)
Bağlantılar: Video
Açılış Konuşması - Kalite Güvencesinden Test Mühendisliğine Geçiş
Ari Shamash (Google)
Bir uygulama oluşturdunuz. Uygulamayı siz başlattınız. Yayına çıkmaya, hacmi artırmaya, fon sağlamaya, sonuna kadar para atmaya ve ardından sıfırdan oynamaya "tetiklenir". Ancak yeni özelliklerle ilgili talepler çok yüksektir. Şimdi de benzeri görülmemiş bir hızda eşsiz bir hıza doğru ilerlemeniz isteniyor. Yanlış! Şimdi önemli olan nedir?
Bu üründen vazgeçip sıfırdan başlamak mümkün değildir. Sahip olduğunuz özellikleri geliştirmeniz ve en yüksek kaliteyi nefes kesici hızda eklemeye devam etmeniz yeterlidir. Ayrıca, şu anda sorun yaşamadığından emin olmanız gerekir. Bunu nasıl yapabilirsiniz? Neyse ki yazılım mühendisliği sektöründe bu yaygın senaryoyu ele alan yeni bir alan ortaya çıkıyor: Google'da buna "test mühendisliği" denir.
Bu konuşma, test mühendisliğinin ne olduğuna, kalite güvencesinden nasıl geliştiğine ve sektörün bir bütün olarak test mühendisliğini nasıl uyguladığına (Google'da nasıl uygulandığına ilişkin spesifik örneklerle) odaklanacaktır.
Sistemlerde Geniş Ölçekte Test Etme @Twitter
James Waldrop (Twitter)
Cemil, Twitter'daki performans testi için kullanılan araçları, süreci ve felsefeyi tartışacaktır. Kodun üretime dağıtılmasından önce Twitter'ın mühendislik ekiplerinin yük testleri gerçekleştirebilmesi için Iago açık kaynak yük testi kitaplığına özellikle odaklanılmış. Bu testlerde, bu testlerden bazılarının (kaynak kodu dahil) uygulama ayrıntıları ve OAuth ile rastgele Thrift protokolleri gibi karmaşık faktörlerin nasıl yönetildiği ele alınacaktır.
Mobil İşletim Sistemi Nasıl Test Edilir?
David Burns (Mozilla) ve Malini Das (Mozilla)
FirefoxOS dünyasına girmeye karar verirken Mozilla'nın karşılaştığı sorun budur. Nereden başlayacağım ve nasıl yapacağım ilgi çekici bir görev olacaktı. Bu sorunu nasıl çözdüğümüzü ve yeni bir çerçeveyi nasıl geliştirdiğimizi öğrenin.
Sürekli Teslim Ardışık Düzeninde Mobil Otomasyon
Igor Dorovskikh (Expedia) ve Kaustubh Gawande (Expedia)
Expedia, 2012'nin başında Mobil Web'e ve iOS/Android uygulamalarına yatırım yapmaya başladı. Aynı zamanda Test Engineers, ürünlere kalite ve test edilebilirlik katmak için ilk olarak test otomasyonu çözümleri geliştirmeye başladı. Bu konuşmada, Expedia'nın çevik geliştirme ve sürekli teslim ortamında otomatik test oluşturmak için açık kaynak araçları kullanma konusundaki deneyimimizi ve öğrendiklerimizi paylaşacağız. Test Piramidi hakkında konuşacağız ve işimize yarayacak belirli açık kaynak araçlarla ilgili daha ayrıntılı bilgi vereceğiz. Salata, web otomasyon aracı Selenium-WebDriver, iOS otomasyon aracı olan Frank, Android otomasyon araçları Robotium ve Calabash ve Sürekli Entegrasyon sistemi Jenkins gibi açık kaynaklı araçlardan bazılarını kullanıyoruz. Buna ek olarak, TDD, Çift Programlama, Oluşturma ve Test Radyatörleri gibi benimsemeye çalıştığımız bazı Çevik dağıtım ilkelerini de paylaşacağız. Son olarak, Agile'e yaptığımız yatırım ve test otomasyonundan elde ettiğimiz avantajlardan bazıları ve bu sürecin sürekli teslim hedeflerimize ulaşmamızı nasıl sağladığını paylaşacağız.
GStreamer ve OpenCV ile Otomatik Set Üstü Kutu Testi
David Röthlisberger (YouTube)
GStreamer'ın komut satırı araçlarını ve OpenCV'sini kullanarak 3 dakikada bir video yakalama görüntü sistemi oluşturacağız. (GStreamer, açık kaynaklı bir medya işleme çerçevesidir. OpenCV - "Open Computer Vision", açık kaynaklı bir resim işleme kitaplığıdır.)
Böyle bir sisteme önde gelen örneklerden biri, set üstü kutularımızın kullanıcı arayüzü testini otomatik hale getirmek için YouView'da geliştirilen açık kaynaklı bir araç olan http://stb-tester.com'dur. Burada, stb-sterster'ı, GStreamer desteklerinin sunduğu esnekliği, açtığı bazı olasılıkları ve gelecekte karşılaşacağımız zorlukları açıklayacağız.
Bağlantılar: Video
Chrome için Webdriver
Ken Kania (Google)
Chrome, Windows'a özel bir tarayıcı olarak kurulduktan sonra Mac, Linux, ChromeOS ve en son Android ve iOS'e genişledi. Bu platformlardaki web uygulamalarının kullanıcı düzeyinde test edilmesi zordu ve çeşitli otomasyon yaklaşımları gerektiriyordu. Bu konuşmada, Chrome ekibinin WebDriver'ı tüm platformlarda kullanılabilir hale getirmek için yaptığı çalışmalar açıklanmaktadır. Bu e-postada, temel yaklaşımla ilgili teknik bir bakış sunulmakta ancak geliştiricilerin, Chrome'un çeşitli platformları için test yazmak üzere yeni ChromeDriver'ı nasıl kullanabileceğine odaklanılmaktadır. Ayrıca, projenin mevcut durumu ve gelecekteki yol haritası da burada ele alınacaktır.
Karma - JavaScript İçin Test Çalıştırıcı
Vojta Jina (Google)
JavaScript uygulamalarının gerçek tarayıcılarda test edilmesini kolay ve keyifli hale getiren test çalıştırıcısı Karma'ya giriş.
Birçok tarayıcı ve cihazda çalışması gereken bir JavaScript uygulaması geliştirilirken test yapmak isteğe bağlı değildir. Ancak bu farklı ortamların tümünde test yapmak zordur. Karma, bu zorlu işi pastaya dönüştürüyor. JavaScript testlerini, telefonunuz veya tabletiniz gibi gerçek tarayıcılarda ya da cihazlarda, doğrudan terminalinizin rahatlığından veya favori IDE'nizden rahatlıkla yürütebilmenizi sağlar.
Bağlantılar: Video
Otomatik Video Kalitesi Ölçümleri
Patrik Höglund (Google)
Evet. Video kalitesi gibi karmaşık ve öznel ölçümleri otomatik olarak test etmek mümkün. Bu konuşma, bir WebRTC video görüşmesinin sürekli ve otomatik uçtan uca testini nasıl geliştirdiğimizi gösterir. Araç zincirine genel bir göz atacak ve bu modeli oluştururken karşılaştığımız zorlukları ele alacağız. Medya testinizi bir üst düzeye nasıl taşıyacağınız konusunda ilham almak istiyorsanız bu sizin için mükemmel olacaktır.
İyi Uygulamalar Olumsuz Olduğunda...
Mineral Mishra (Netflix)
Mobil ve tablet bilişimin yükselişi, uygulama geliştirme platformlarıyla yazılım sektörünü hızlandırdı. Bilişim platformlarında tüketici uygulamaları geliştirmenin son kullanıcılar için kendi sihirli deneyimi vardır. Tüketicilere yönelik yazılım şirketleri, bu platformlar için uygulama geliştirirken her zaman en iyi sonucu vermeye çalışır. Ancak uygulama geliştirmedeki en büyük zorluk, şirketlerin uygulamanın ilk sürümünü kullanıma sunmasından sonra başlar. Tüketiciler ve yazılım şirketleri en yeni özellik ve işlevleri en kısa sürede geliştirme aşamasından geçirmek istiyor. Bu da yığının her katmanında sürekli kod kaybına neden olur. Kullanıcı arayüzü otomasyon mühendisleri olarak, uygulama sorunlarını erkenden tespit etmek için çeşitli tespit sistemleri geliştiriyoruz. Bu konuşmada, uygulama katmanı dışındaki sorunları bulmamıza yardımcı olacak ancak kullanıcı deneyimini olumsuz etkileyecek olan bir tespit sisteminin arkasındaki bazı zorlukları ve başarıları paylaşacağım.
Eğitici Oyunlar ve Test Amaçlı Eğitim Oyunları
Tao Xie (Kuzey Carolina Devlet Üniversitesi)
Bu konuşmada, yüz binlerce kullanıcıya ölçeklendirilebilen bir online programlama sisteminde otomatik notlandırmanın temelini oluşturan otomatik test oluşturma yönteminden yararlanan Pex4Fun (http://www.pexforfun.com/) sunulmaktadır. Sınıf dışında programlama odaklı bir oyun deneyimi sunan bu kurs, kullanıcıları parametreli birim testleri yazma gibi test etme gibi çeşitli programlama ve yazılım mühendisliği becerileri edinmeye teşvik eder. Pex4Fun, ödevlere not vermenin bilinen sorununa önemli ölçüde katkıda bulunuyor ve etkileşimli oyunları temel alan eğlenceli bir öğrenme deneyimi sağlıyor. Pex4Fun, toplulukta büyük popülerlik kazandı: Haziran 2010'da herkesin kullanımına sunulduğundan beri, "Pexx'e Sorun!" düğmesinin (kullanıcıların Pex4Fun'da oyun çözme amaçlı inisiyatifini belirtir) tıklama sayısı, 2013'ün başlarından itibaren bir milyondan fazlaya ulaştı.
Açılış Konuşması - Facebook Android'de Facebook'u Nasıl Test Ediyor?
Simon Stewart (Facebook)
Facebook, mevcut en popüler Android uygulamalarından biridir. Bu konuşmada, Facebook'un her sürümün ne kadar iyi olduğundan emin olmak için ne yaptığını öğreneceksiniz. Kodu yönetme yöntemimizden, test yaklaşımlarımıza ve köpek mamasına kadar her konuyu ele alacağız.
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üncelleme [Ekim 2013]: Espresso artık açık kaynak. https://code.google.com/p/android-test-kit/ adresine göz atın.
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 (Google)
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.