İyi bir çevrimiçi kaynağa işaret edemiyorum (bu konulardaki İngilizce Wikipedia makaleleri iyileştirilebilir olma eğilimindedir), ancak temel test teorisini de kapsayan duyduğum bir dersi özetleyebilirim.
Test modları
Birim testleri veya entegrasyon testleri gibi farklı test sınıfları vardır . Birim testi, kendi başına alınan tutarlı bir kod parçasının (işlev, sınıf, modül) beklendiği gibi çalıştığını iddia ederken, bir entegrasyon testi bu tür birden çok parçanın birlikte doğru çalıştığını iddia eder.
Test durumu, bir kod parçasının yürütüldüğü bilinen bir ortamdır , örn. Belirli test girişi kullanılarak veya diğer sınıflarla alay etmek. Kodun davranışı daha sonra beklenen davranışla, örneğin belirli bir dönüş değeriyle karşılaştırılır.
Bir test sadece bir hatanın varlığını kanıtlayabilir, asla tüm hataların yokluğunu kanıtlayabilir. Testler program doğruluğuna bir üst sınır koydu .
Kod kapsamı
Kod kapsamı metriklerini tanımlamak için kaynak kodu, her düğümün kodun doğrusal bir segmentini içerdiği bir kontrol akış grafiğine çevrilebilir . Kontrol, bu düğümler arasında sadece her bloğun sonunda akar ve her zaman koşulludur (koşul varsa, düğüm A'ya git, başka düğüm B'ye git). Grafikte bir başlangıç düğümü ve bir bitiş düğümü vardır.
- Bu grafikte, ifade kapsamı , ziyaret edilen tüm düğümlerin tüm düğümlere oranıdır. Tam ifade kapsamı kapsamlı testler için yeterli değildir.
- Dal kapsamı , CFG'deki düğümler arasındaki tüm ziyaret edilen kenarların tüm kenarlara oranıdır. Bu, döngüleri yeterince test etmez.
- Yol kapsamı , ziyaret edilen tüm yolların tüm yollara oranıdır; burada yol, başlangıçtan bitiş düğümüne kadar herhangi bir kenar dizisidir. Sorun, döngülerde sonsuz sayıda yol olabileceğidir, bu nedenle tam yol kapsamı pratikte test edilemez.
Bu nedenle, koşul kapsamını kontrol etmek genellikle yararlıdır .
- Gelen basit koşul kapsama , her atom koşul kez doğru ve yanlış kez - ama bu tam deyimi kapsama garanti etmez.
- Gelen çoklu durum kapsama , atomik koşullar tüm kombinasyonları almış
trueve false. Bu, tam şube kapsamı anlamına gelir, ancak oldukça pahalıdır. Program, belirli kombinasyonları hariç tutan ek kısıtlamalara sahip olabilir. Bu teknik, şube kapsamı elde etmek için iyidir, ölü kodu bulabilir, ancak yanlış durumdan kaynaklanan hataları bulamaz .
- Gelen Minimal çoklu durum kapsama , her atomik ve kompozit koşul doğru ve yanlış defa. Hala tam şube kapsamı anlamına gelmektedir. Birden çok koşul kapsamının bir alt kümesidir, ancak daha az test vakası gerektirir.
Koşul kapsamı kullanarak test girişi oluştururken kısa devre dikkate alınmalıdır. Örneğin,
function foo(A, B) {
if (A && B) x()
else y()
}
ihtiyaçları ile test edilecek foo(false, whatever), foo(true, false)ve foo(true, true)tam minimum çoklu durum kapsama.
Birden çok durumda olabilen nesneleriniz varsa, akışları kontrol etmeye benzer tüm durum geçişlerini test etmek mantıklı görünmektedir.
Daha karmaşık kapsam metrikleri vardır, ancak bunlar genellikle burada sunulan metriklere benzer.
Bunlar beyaz kutu test yöntemleridir ve kısmen otomatikleştirilebilir. Bir birim test paketinin seçilen herhangi bir metrik tarafından yüksek kod kapsamına sahip olması gerektiğini unutmayın , ancak% 100 her zaman mümkün değildir. Hataların belirli yerlere enjekte edilmesi gereken istisna işlemeyi test etmek özellikle zordur.
Fonksiyonel testler
Daha sonra , uygulamayı bir kara kutu olarak görüntüleyerek kodun spesifikasyona uyduğunu iddia eden fonksiyonel testler vardır. Bu tür testler, birim testleri ve entegrasyon testleri için faydalıdır. Mümkün olan tüm giriş verileri ile test etmek imkansız olduğu için (örneğin, tüm olası dizelerle dize uzunluğunu test etmek), girdiyi (ve çıktıyı) eşdeğer sınıflara gruplamak yararlıdır - eğer length("foo")doğruysa, foo("bar")muhtemelen işe yarayacaktır. Giriş ve çıkış denklik sınıfları arasındaki olası her kombinasyon için en az bir temsili giriş seçilir ve test edilir.
Ek olarak test edilmelidir
- Kenar durumlarda
length(""), foo("x"), length(longer_than_INT_MAX),
- dil tarafından izin verilen, ancak işlevin sözleşmesi tarafından izin verilmeyen değerler
length(null)ve
- olası önemsiz veriler
length("null byte in \x00 the middle")…
Rakamlarla bu test etmek 0, ±1, ±x, MAX, MIN, ±∞, NaNve iki komşu şamandırayı test etmek için kayan nokta karşılaştırmaları anlamına gelir . Başka bir ilave olarak, rastgele test değerleri denklik sınıflarından seçilebilir. Hata ayıklamayı kolaylaştırmak için, kullanılan tohumu kaydetmeye değer…
Fonksiyonel olmayan testler: Yük testleri, Gerilme testleri
Bir yazılım parçası, test edilmesi gereken işlevsel olmayan gereksinimlere sahiptir. Bunlar, tanımlanan sınırlardaki testleri (yük testleri) ve bunların ötesini (stres testleri) içerir. Bir bilgisayar oyunu için, bu bir yük testinde saniyede minimum sayıda kare olduğunu iddia ediyor olabilir. Bir web sitesi, beklendiği kadar ziyaretçinin sunucuları dövüştüğü tepki sürelerini gözlemlemek için stres testine tabi tutulabilir. Bu tür testler sadece tüm sistemler için değil, tek işletmeler için de geçerlidir - bir karma tablo bir milyon girişle nasıl bozulur?
Diğer test türleri, senaryoların simüle edildiği tüm sistem testleri veya geliştirme sözleşmesinin yerine getirildiğini kanıtlamak için kabul testleridir.
Test dışı yöntemler
yorumlar
Kalite güvencesi için kullanılabilecek test dışı teknikler vardır. Örnekler, izlenecek yollar, resmi kod incelemeleri veya çift programlamadır. Bazı parçalar otomatikleştirilebilirken (örn. Tiftik kullanarak), bunlar genellikle zaman yoğundur. Bununla birlikte, deneyimli programcılar tarafından yapılan kod incelemelerinde hata bulma oranı yüksektir ve otomatik testin mümkün olmadığı tasarım sırasında özellikle değerlidir.
Kod incelemeleri çok iyi olduğunda, neden hala testler yazıyoruz? Test paketlerinin en büyük avantajı, otomatik olarak çalışabilmeleridir (çoğunlukla) ve regresyon testleri için çok yararlıdır .
Resmi doğrulama
Resmi doğrulama geçer ve kodun belirli özelliklerini kanıtlar . Manuel doğrulama çoğunlukla kritik parçalar için geçerlidir, tüm programlar için daha az geçerlidir. Provalar program doğruluğuna daha düşük bir sınır koymaktadır . Provalar belirli bir dereceye kadar otomatikleştirilebilir, örn. Statik tip kontrolör.
Bazı değişmezler assertifadeler kullanılarak açıkça kontrol edilebilir .
Tüm bu tekniklerin yerleri vardır ve birbirini tamamlarlar. TDD, fonksiyonel testleri ön plana çıkarır, ancak kod uygulandıktan sonra testler kapsama metrikleri ile değerlendirilebilir.
Test edilebilir kod yazmak, ayrı olarak test edilebilen küçük kod birimleri yazmak anlamına gelir (uygun ayrıntı düzeyinde yardımcı işlevler, tek sorumluluk ilkesi). Her bir işlev ne kadar az argüman alırsa o kadar iyidir. Böyle bir kod aynı zamanda sahte nesnelerin örneğin bağımlılık enjeksiyonu yoluyla sokulması için de uygundur.
double pihole(double value) { return (value - Math.PI) / (value - Math.PI); }öğrendiğim şu klasik örneği düşünün . Bu kodun tam olarak tek bir deliği vardır , bu delik tek başına kara kutu testinden otomatik olarak bulunamaz. Math'da böyle bir delik yoktur. Matematikte, tek taraflı sınırlar eşitse deliği kapatmanıza izin verilir.