Sıkı bir anlamda, test paketinin kalitesi belirlenene kadar herhangi bir iddiada bulunmak adil değildir. Testlerin çoğu önemsiz veya birbirini tekrarlıyorsa testlerin% 100'ünü geçmek anlamlı değildir.
Soru şudur: Proje tarihinde, bu testlerden herhangi biri hataları ortaya çıkardı mı? Bir testin amacı hataları bulmaktır. Ve eğer yapmadılarsa, test olarak başarısız oldular. Kod kalitesini artırmak yerine, size yalnızca yanlış bir güvenlik duygusu veriyor olabilirler.
Test tasarımlarınızı geliştirmek için (1) beyaz kutu teknikleri, (2) kara kutu teknikleri ve (3) mutasyon testi kullanabilirsiniz.
(1) Test tasarımlarınıza uygulamak için bazı iyi beyaz kutu teknikleri. Bir whitebox testi, belirli kaynak kodu göz önünde bulundurularak yapılır. Beyaz kutu testinin önemli bir yönü kod kapsamıdır:
- Her fonksiyon denir mi? [Fonksiyonel kapsam]
- Her ifade yürütülüyor mu? [İfade kapsamı-- Hem işlevsel kapsam hem de beyan kapsamı çok basittir, ancak hiç olmamasından iyidir]
- Her karar için (
ifya da gibi while), onu doğru olmaya zorlayan ve diğerlerini yanlış olmaya zorlayan bir testiniz var mı? [Karar kapsamı]
- Bağlaç (kullanım
&&) veya ayrılma (kullanım ||) olan her koşul için, her alt ifadenin doğru / yanlış olduğu bir sınaması var mı? [Durum kapsamı]
- Döngü kapsamı: 0 yineleme, 1 yineleme, 2 yineleme zorlayan bir testiniz var mı?
- Her biri
breakbir döngüden kaplanmış mı?
(2) Gereksinimler mevcut olduğunda Blackbox teknikleri kullanılır, ancak kodun kendisi yoktur. Bunlar yüksek kaliteli testlere yol açabilir:
- Blackbox testleriniz birden çok test hedefini kapsıyor mu? Testlerinizin "şişman" olmasını istersiniz: Sadece X özelliğini test etmekle kalmaz, aynı zamanda Y ve Z'yi de test ederler. Farklı özelliklerin etkileşimi, hataları bulmanın harika bir yoludur.
- "Yağ" testi istemediğiniz tek durum, bir hata durumunu test ettiğiniz zamandır. Örneğin, geçersiz kullanıcı girişi testi. Birden çok geçersiz giriş testi hedefi (örneğin, geçersiz bir posta kodu ve geçersiz bir sokak adresi) elde etmeye çalıştıysanız, büyük olasılıkla bir vaka diğerini maskeliyordur.
- Girdi türlerini göz önünde bulundurun ve girdi türleri için bir "denklik sınıfı" oluşturun. Örneğin, kodunuz bir üçgenin eşdeğer olup olmadığını görmek için test ederse, kenarları olan üçgen (1, 1, 1) kullanan test muhtemelen test verisi (2, 2, 2) ve (3, 3, 3) bulacaktır. Zamanınızı diğer girdi sınıflarını düşünerek geçirmek daha iyidir. Örneğin, programınız vergileri işliyorsa, her vergi grubu için bir test isteyeceksiniz. [Buna denklik bölümleme denir.]
- Özel durumlar genellikle kusurlarla ilişkilidir. Test verileriniz ayrıca bir eşdeğerlik görevinin kenarlarında, üstünde veya altında olanlar gibi sınır değerlerine sahip olmalıdır. Örneğin, bir sıralama algoritmasını test ederken, boş bir dizi, tek bir öğe dizisi, iki öğeli bir dizi ve ardından çok büyük bir dizi ile test etmek istersiniz. Sınır vakalarını yalnızca girdi için değil çıktı için de dikkate almalısınız. [Bu çağrı sınır-değer analizidir.]
- Başka bir teknik "Hata tahminidir" dir. Programınızın kırılmasını sağlayabileceğiniz bazı özel kombinasyonları denediğinizde hissiniz var mı? O zaman sadece dene! Unutmayın: Hedefiniz, programın geçerli olduğunu doğrulamak için değil, hataları bulmaktır . Bazı insanlar hata tahmin etme yeteneğine sahiptir.
(3) Son olarak, beyaz kutu kapsamı ve uygulanan blackbox teknikleri için çok sayıda güzel testiniz olduğunu varsayalım. Başka ne yapabilirim? Testlerinizi Test Etme Zamanı . Kullanabileceğiniz tekniklerden biri Mutasyon Testi'dir.
Mutasyon testi altında, hata yaratma umuduyla programınızda (bir kopyası) değişiklik yaparsınız. Bir mutasyon şunlar olabilir:
Bir değişkenin referansını başka bir değişkene değiştirme; Abs () işlevini ekleyin; 'Den daha azdan daha büyük' e değiştirin; Bir ifadeyi silme; Bir değişkeni sabit ile değiştirin; Geçersiz kılma yöntemini silme; Bir süper yönteme başvuruyu silme; Bağımsız değişken sırasını değiştir
Programınızın çeşitli yerlerinde birkaç düzine mutant oluşturun [programın test etmek için derleme yapması gerekecektir]. Testleriniz bu hataları bulamazsa, şimdi programınızın mutasyona uğramış sürümünde hatayı bulabilecek bir test yazmanız gerekir. Bir test hatayı bulduğunda, mutantı öldürdünüz ve başka bir tane deneyebilirsiniz.
Zeyilname : Bu etkiyi belirtmeyi unuttum: Hatalar kümelenme eğilimindedir . Bunun anlamı, bir modülde ne kadar çok hata bulursanız, daha fazla hata bulma olasılığınızın o kadar yüksek olmasıdır. Bu nedenle, başarısız olan bir testiniz varsa (yani, test başarılıdır, çünkü hedef hataları bulmaktır), sadece hatayı düzeltmeniz gerekir, aynı zamanda modülü kullanarak daha fazla test yazmalısınız. yukarıdaki teknikler.
Hataları sabit bir oranda bulduğunuz sürece, test çalışmaları devam etmelidir. Yalnızca, bulunan yeni hataların oranında bir düşüş olduğunda, bu geliştirme aşaması için iyi test çabaları yaptığınızdan emin olmalısınız.