65.000.000.000 test çalışması

65.000.000.000 test grubunun nasıl çalıştırılacağı sorulmuştu ve bu kadar çok testle bir projeye sahip olmanın normal olup olmadığını merak ediyorum.

Bu özelliğe sahip projelerde çalıştınız mı?

65 milyar testle, olası tüm girişleri test etmeniz isteniyor gibi gözüküyor. Bu kullanışlı değildir - temel olarak işlemcinizin düzgün çalıştığını, kodunuzun doğru olmadığını test edersiniz.

Bunun yerine denklik sınıflarını test ediyor olmalısınız . Bu, test girişi aralığınızı büyük ölçüde azaltır.

Ayrıca, sisteminizi daha küçük parçalara bölüp ayıramayacağınızı düşünün. Her parçanın izolasyonda test edilmesi daha kolay olacaktır ve ardından tüm parçaları bir araya getiren bazı entegrasyon testleri gerçekleştirebilirsiniz.

Hala bu girdi kombinasyonlarından bazılarının çalıştığına dair güvence istiyorsan, belki fuzz testini deneyebilirsin . Çok sayıda farklı girdiyi test etmenin faydalarından bazılarını elde edeceksiniz, ancak bunların 65 milyarını da çalıştırmadan.

Bu gerçek bir test paketi ise, üzerinde çalışacak bir yere gitmek istemezsiniz.

Bir test cihazının tüm işi, “doğru” sonuçlara sahip olduğunuzdan emin olmak için yeterince test yapmak ve makul bir sürede çalıştırılabilecek kadar az sayıda test yazmak arasında bir denge kurmaktır.

Pek çok test "denklik sınıfları" olarak soyutlanabilir, yani 3 milyar test yapmak yerine, 1’i siz denersiniz, bu denklik sınıfındaki tüm diğer testlerin başarıyla sonuçlanacağına dair makul bir güven düzeyi sağlarsınız. onları çalıştıran zaman.

65 milyar test yapmayı düşünenlerin, denklik sınıflarına testleri soyutlamak için daha iyi bir iş yapmaları gerektiğini söylemelisiniz.

Muhtemelen, teste giren sisteme olası tüm girdi kombinasyonlarını hesaplayarak veya döngüsel karmaşıklığı hesaplayarak ve bu benzersiz uygulama yollarının her biri için bir test yapılması gerektiğini varsayarak 65 milyar test rakamına ulaştınız.

Gerçek sınavlar böyle yazılmaz, çünkü diğer afiş ve yorumcularda belirtildiği gibi, 65 milyar çalıştırmak için gereken teknik güçTestler şaşırtıcı. Bu, iki 32-bit değerin her olası permütasyonunu takarak ve sonucu kontrol ederek iki tamsayı eklemek için bir yöntem kullanan bir test yazmak gibidir. Bu tamamen delilik. Çizgiyi çizmeli ve olası tüm test durumlarının bir alt kümesini tanımlamalısınız; bunlar aralarında sistemin girdiler aralığında beklendiği gibi davranmasını sağlayacaktır. Örneğin. birkaç "normal" sayı eklemeyi denersiniz, birkaç negatif sayı senaryosunu test eder, taşma senaryoları gibi teknik sınırları test eder ve hatayla sonuçlanacak senaryoları test edersiniz. Belirtildiği gibi, bu çeşitli testler "eşdeğerlik sınıfları" uygular; bilinen herhangi bir "aykırı" ile birlikte olası girdilerin temsili bir örneğini almanıza izin veriyorlar,

Roma Sayısal Jeneratör, temel kod kataslarından birini düşünün. TDD teknikleri kullanılarak "dojo" tarzında yapılacak görev, 1'den 3000'e kadar herhangi bir sayıyı kabul edebilecek ve bu sayı değeri için doğru Romen rakamını üretebilecek bir fonksiyon yazmaktır.

Bu sorunu, her defasında 3000 birim sınaması yazıp geçerek çözemezsiniz. Bu delilik; Alıştırma normalde bir ila iki saat sürer ve her bir bireysel değeri test etmek için günlerce orda olursunuz. Bunun yerine, akıllısın. En basit temel durumla (1 == "I") başlar, "en az kodlu" bir strateji ( return "I";) kullanarak bunu uygular ve sonra kodun başka bir beklenen senaryoda (2 == "yanlış davranacağına bakın) II "). Durulayın ve tekrarlayın; Büyük olasılıkla, ilk uygulamanızı "I" karakterini gerektiği kadar tekrar eden bir şeyle değiştirdiniz (gibi return new String('I',number);). Bu açıkça III için bir sınavdan geçecek, bu yüzden rahatsız etmeyin; bunun yerine testi şu anki uygulamanın kazandığını bildiğin 4 == "IV" için yazarsın.

Veya, daha analitik bir tarzda, kodla (veya olması gereken) verilen her koşullu kararı inceliyor ve her kararın olası sonuçlarının her biri için kodu girmek için tasarlanmış bir test yazıyorsunuz. 5 if ifadeniz varsa (her biri doğru ve yanlış bir dalı varsa), her biri diğerinden tamamen bağımsızdır, 32 değil 10 testi kodlarsınız. Her test, belirli bir olası karar hakkında iki şey söyleyecek şekilde tasarlanır; önce doğru kararın verilmiş olması, sonra da bu şartlar altında girilen kodun doğru olması. Sen yok bağımsız kararların olası her permütasyon için bir test kodu. Kararlar bağımlıysa, bunları daha fazla kombinasyon halinde test etmeniz gerekir, ancak daha az sayıda kombinasyon vardır, çünkü bazı kararlar yalnızca başka bir kararın belirli bir sonucu olduğunda alınabilir.

Bu "normal" mi? Burada "normal" ortalama veya tipik bir deneyim olarak tanımlanır. Hiç böyle bir projede çalışmak zorunda kaldığımı söyleyemem, ancak birkaç milyon bitin birisinin çevrileceği bir projedeydim. Bunu test etmek ... zor bir işti.

Potansiyel olarak gerekli mi? Bu, projenin garantilerine ve özelliklerine bağlıdır. İlk başta anlamak biraz inandırıcı değil, ancak sorunuzun özellikleri açık.

Diğerlerinin (MichaelT) belirttiği gibi, bu görevi seri testlerle tamamlama zamanı pratik değildir. Böylece paralelleştirme ilk düşünceniz haline gelir. Bu soruna kaç test sistemi atabilirsiniz ve bu çoklu sistemlerin sonuçlarını harmanlamak için ne gibi desteğiniz var?

Test ettiğiniz cihazın veya algoritmanın güvenilir bir şekilde çoğaltılmasının garantisi nedir? Yazılım çoğaltma işleminde oldukça güvenilirdir, ancak donanım aygıtlarında (özellikle ilk nesil) üretim sorunları olabilir. Bu durumda yanlış bir test hatası ya kötü bir algoritma olduğunu ya da cihazın doğru bir şekilde bir araya gelmediğini gösterebilir. Bu iki durumu birbirinden ayırmanız mı gerekiyor?

Test sistemlerini kendileri nasıl doğrulayacağınızı da düşünmeniz gerekecektir. Bu kadar çok test vakası için meşru bir neden varsayarak, çok fazla otomasyona ihtiyacınız olacak. Test vakalarınızı oluştururken hata yapmadığından emin olmak için bu otomasyonun denetlenmesi gerekir. Hatalar için yapılan nokta kontrolleri, samanlıkta bir iğne bulmaya eşdeğer olacaktır.

Bu arstechnica bağlantısı , testle ilgili düşünceleriniz hakkında biraz fikir verebilir veya olmayabilir. GPU kümeleri, kaba kuvvet kırma parolaları için yaygın olarak kullanılır. Makalede alıntı yapılan, yapabilir can cycle through as many as 350 billion guesses per second, böylece 65B testlerinizi perspektif içine sokabilirsiniz . Muhtemelen farklı bir alandır, ancak göreve farklı açılardan yaklaşmanın uygulanabilir bir çözüm getirebileceğini gösterir.

Bunun için mümkün olduğunu sanmıyorum korumak böylece onları tartışmalı olabilir çalışan 6.5e + 10 testleri o ilk yer. Tüm paketleri olan Debian gibi en büyük projelerde bile sadece birkaç yüz milyon SLOC var.

Ancak yine de çok sayıda test yapmak zorunda kalırsanız, birkaç strateji vardır.

• Hepsini çalıştırma. Büyük olasılıkla her test her kod yoluna bağlı değildir. Alt sistemler ve testleri arasındaki ve test paketleri arasındaki bağımlılıkları tanımlayın; yalnızca belirli bir değişiklikle ilgili birim testlerini, yalnızca bu birim testlerine bağlı entegrasyon testlerini vb. Çalıştırabilirsiniz.

• Paralel olarak çalıştırın. Muazzam büyüklükteki kod tabanı ile muhtemelen büyük bir inşaat çiftliğiniz var (JetBrains'te nispeten küçük bir operasyonda, sadece IDEA sürekli inşa / entegrasyon çiftliğinde çalışan 40-50 inşaat acentesi vardı). Ünite testleri bağımsız olduğundan ve entegrasyon testleri zaten oluşturulmuş kodu yeniden kullanabildiğinden, testlerin paralel hale getirilmesi nispeten kolaydır.

• Erken koşmayı kes. Belirli bir test odasının başka bir test odasının doğruluğu üzerindeki makul işleyişine bağlı olduğunu biliyorsanız, bir bağlantının başarısız olduğunu gördükten sonra tüm zinciri kesebilirsiniz.

Yasal Uyarı: Ben profesyonel bir test mühendisi değilim. Yukarıdakileri bir tuz taneleri ile alın.

Her ne kadar daha az testle gizlice girmeyi denemek konusunda birkaç iyi öneri olmasına rağmen, sisteminizin sadece 65 milyar giriş kombinasyonuna sahip olduğundan şüpheliyim. Bu 36 bit girdiden daha az. Yukarıda verilen tüm tavsiyeleri aldığınızı varsayalım.

Her testin çalışması yaklaşık bir milisaniye sürerse ve testleri yalnızca 10 işlemciye (bir normal PC) dağıtırsanız, test 69 günden biraz daha uzun bir süre sonra çalışır. Bu bir süre, ama tamamen mantıksız değil. 100 işlemciye (bir düzine normal PC veya bir makul sunucu PC) dağıtın ve testler 7 günden daha kısa bir sürede tamamlanacaktır. Bunları regresyon kontrol etmek için her hafta çalıştırabilirsiniz.