Modül Testi Nedir? Tanım, Örnekler

⚡ Akıllı Özet

Modül testi, derlenmiş program yerine tek tek alt programları, alt rutinleri, sınıfları ve prosedürleri kontrol eder; bu nedenle hatalar, bulunması ve onarılması ucuz olan küçük, iyi anlaşılmış bir kod bloğu içinde ortaya çıkar.

🎯 Amaç: Amaç, modülün çalıştığını göstermek değil, modüldeki hataları ortaya çıkarmaktır.
⚪ Oryantasyon: Bu teknik büyük ölçüde beyaz kutu yöntemine dayanır ve şartnameden alınan siyah kutu örnekleriyle desteklenir.
⏩ Paralellik: Birden fazla modül aynı anda test edilebildiğinden, genel test süresi kısalır.
🔗 İki yöntem: Modüller ya kademeli olarak, adım adım ya da tek seferde, kademeli olmayan bir şekilde birleştirilir.
🧰 İskele: Sürücüler bir modüle test verileri sağlarken, saplamalar ise çağırdığı modüllerin yerine geçer.
🆚 mülkiyet: Test uzmanları kodlama bittikten sonra modül testleri yazarken, geliştiriciler kodlama sırasında birim testleri yazarlar.
⚠️ Zorluklar: Artımlı olmayan çalışmalar, yanlış anlaşılan test tekrarları ve sık sık yapılan hata ayıklama işlemleri, çabanın büyük kısmını tüketir.

Devamını Oku

Modül Testi Nedir?

Modül testi Modül testi, bir programdaki tek tek alt programları, alt rutinleri, sınıfları veya prosedürleri kontrol eden bir yazılım test türüdür. Yazılım programının tamamını bir kerede test etmek yerine, modül testi programın daha küçük yapı taşlarını test etmeyi önerir.

Modül testi büyük ölçüde beyaz kutu odaklıdır. Modül testinin amacı modülün düzgün çalışmasını göstermek değil, içinde bir hata olduğunu göstermektir. Bu tersine çevirme önemlidir: hiçbir şey bulamayan bir test çok az şeyi doğrulamış olurken, bir hatayı ortaya çıkaran bir test görevini yerine getirmiştir.

Modül düzeyinde test, aynı zamanda test sürecine paralellik kazandırmayı da mümkün kılar, çünkü bu sayede tam bir derlemenin tamamlanmasını beklemek yerine birden fazla modülü eş zamanlı olarak test etme fırsatı doğar.

Neden Modül Testi yapılmalı?

Modül testinin yapılması önerilir çünkü bu, hata tespitinin ekonomik yönlerini değiştirir.

Programın daha küçük bölümlerindeki hataları veya kusurları tespit etme olasılığı artar.
Birden fazla modül aynı anda test edilebilir ve bu nedenle yaklaşım paralel testleri destekler.
Her modül kendi başına ele alındığından, testlerin karmaşıklığı kolaylıkla yönetilebilir.
Modüllerden birinde bulunan bir arıza şudur: tracAz miktarda kod içerebildiği için hata ayıklama süresi önemli ölçüde azalır.

Modül Testi nasıl yapılır?

Tasarımı bir test durumu Modül testinin önemli bir bölümüdür. Bir modül testi için test senaryoları tasarlarken, test uzmanının iki şeyi dikkate alması gerekir.

Modül için spesifikasyon
Modülün kaynak kodu

Modülün mantığını aşağıdaki yöntemlerden birini veya birkaçını kullanarak analiz edin. Beyaz kutu ve daha sonra bu test durumlarını yöntemler uygulayarak tamamlayın. Kara kutu Modül spesifikasyonuna yönelik yöntemler. Gerçekçi değerler, seçilen yollar kadar önemlidir, bu nedenle hazırlıklı olun. test verisi Vakalarla eş zamanlı olarak, sonrasında değil.

Test senaryoları tasarlandıktan sonraki adım, test için modülleri birleştirmektir. Kullanılan yöntem ya bir artımlı ya da artımlı olmayan yöntemi.

Artımsız yöntem — Tüm modüller bağımsız olarak test edilir. Önce tüm modüller birleştirilir, ardından programın tamamı test edilir.
Artımlı yöntem — Her modül önce test edilir ve ardından kademeli olarak test edilen koleksiyona eklenir. Adım adım yeniden test işlemi gerçekleştirilir.
Artımlı test yönteminde iki yaklaşım vardır, yukarıdan aşağıya hem de aşağıdan yukarıya test.
Seçilen verilerle modülü çalıştırmak için, test verilerini sağlamak, yürütmeyi izlemek ve sonuçları yakalamak üzere bir sürücüye ihtiyaç duyulmaktadır.

İki yöntem arasındaki seçim, kurulum çabası ve teşhis kolaylığı arasında bir denge kurmayı gerektirir.

Görünüş	Artımlı yöntem	Artımsız yöntem
Kombinasyon	Test edilmiş bir koleksiyona, her seferinde bir modül ekleniyor.	Tüm modüller birleştirildi ve ardından birlikte test edildi.
İskele gerekli	Aşamalı olarak yazılan daha fazla sürücü ve bağlantı parçası.	Gerçek modüller mevcut olduğundan, daha az test çifti kullanılır.
Arıza izolasyonu	Güçlü — yeni eklenen modülde bir arıza noktası	Zayıf — bir arıza her yerden kaynaklanabilir.
En uygun	Birbirleriyle etkileşim halinde olan birçok modüle sahip büyük yapılar	Az sayıda modüle ve düşük bağlantıya sahip küçük programlar

Modül Testinde Sürücüler ve Saplamalar

Yukarıda bahsedilen sürücü, bir çiftin yarısıdır. Test edilen bir modül nadiren çağrı zincirinin en üstünde veya en altında yer aldığından, test uzmanları, eksik olan her şey için sahte kod kullanırlar.

Sürücü — Test edilen modülün üstündeki çağıran modülü değiştirir. Test verilerini sağlar, modülü çağırır, yürütmeyi izler ve sonuçları yakalar. Aşağıdan yukarıya test, sürücülere bağlıdır çünkü alt modüller üst modüllerden önce hazırdır.
koçan — Test edilen modülün altındaki çağrılan modülü değiştirir. Çağrıyı kabul eder ve test edilen modülün yolunu tamamlayabilmesi için sabit, bilinen bir yanıt döndürür. Yukarıdan aşağıya test, daha üstteki modüller önce hazır olduğundan, yer tutuculara (stubs) bağlıdır.

Örnek bir uygulama, eşleştirmeyi somutlaştırır. Ödeme hesaplama modülü tamamlanmışken, onu çağıran ödeme ekranı henüz tamamlanmamışsa, bir sürücü modüle bir dizi sipariş toplamı gönderir ve geri gelenleri kaydeder. Modülün çağırdığı vergi sorgulama hizmeti de tamamlanmamışsa, bir yedek parça sabit bir vergi oranı döndürür, böylece hesaplama yine de çalışır. İskelet yapısının hiçbir parçası gönderilmez; gerçek modüller geldiğinde her ikisi de atılır, bu nedenle yanlış anlama testi çiftleri daha sonra tekrar eden bir zorluk olarak listelenmiştir.

Modül Testi için Örnek İpuçları

Modül testine başlamadan önce dikkate almanız gereken birkaç ipucu şunlardır.

RevKullanmadan önce test senaryolarını inceleyin.
Tutarsızlıkların kaynağı konusunda kafa karışıklığından kaçının.
Otomatik test araçlarını kullanın.
Değiştirilmemesi gereken değişkenleri inceleyin.
Kendi kendini test etmeyi önlemek için test cihazları arasında modülleri değiştirin.
Test senaryolarını tekrar kullanın.

Beşinci ipucu, uzunluğundan daha fazla önem taşıyor. Sadece yeni yazılmış modülü test eden bir geliştirici, hataya neden olan aynı varsayımları tekrarlar; bu nedenle modülleri kişiler arasında değiştirmek, elde edilebilecek en ucuz kalite iyileştirmelerinden biridir.

Birim Testi ve Modül Testi

Bu iki terim birçok ekipte birbirinin yerine kullanılsa da, yazarlığı ve kapsamı farklıdır.

Modül Testi	Birim Testi
Modül testleri, bir geliştirici tarafından bazı kodlar yazıldıktan sonra bir test uzmanı tarafından yazılan testlerin bir koleksiyonudur.	Birim testleri Testler, yazılım geliştirme sürecinde bir geliştirici tarafından yazılan testlerin bir koleksiyonudur.
Modül testleri, birim testlerinin birleştirilmesini içerebilir.	Birim testleri, birimleri tek başına test edebilir.

Modül Testi, Bileşen Testi ve Entegrasyon Testi Arasındaki Farklar

Modül testi, onunla karıştırılması kolay olan iki komşu seviyenin yanında yer alır. Tablo, bunları neyin test edildiğine ve normalde kimin gerçekleştirdiğine göre ayırır.

Görünüş	Modül testi	Bileşen testi	Entegrasyon testi
test altında	Bir alt program, sınıf veya prosedür	Doğrudan bağımlılıklarıyla birlikte, kendi başına bağımsız bir bileşen.	Birleştirilmiş modüller arasındaki arayüzler
Olağan sahibi	Kod yazıldıktan sonra testçi.	Test cihazı	Entegrasyon test uzmanı
iskele	Sürücüler ve aks milleri	Harici bağımlılıklar için taslaklar	Giderek daha az sayıda test çifti
Ortaya çıkan kusur	Modül içinde mantık hatası	Bileşende davranış hatası	Arayüz ve veri iletim hatası

Günlük kullanımda bileşen testi ve modül testleri sıklıkla aynı faaliyet olarak ele alınırken, entegrasyon testi Başlangıcı ancak her bir modülün kendi başına başarılı bir şekilde tamamlanmasının ardından yapar.

Modül Testindeki Zorluklar

Modül testi uygulamaya konulduğunda ekiplerin en sık karşılaştığı zorluklar bunlardır.

Artımlı olmayan testler daha fazla çalışma gerektirir — Her şeyi önce bir araya getirmek, tek bir hatanın test uzmanlarını tüm programı baştan başlatmaya zorlayabileceği anlamına gelir.
Test çiftlerini yanlış anlama — Gerçekçi olmayan bir değer döndüren bir kod parçası, hiçbir şeyi kanıtlamayan yeşil bir çalıştırma üretir.
Testlerde hata ayıklama sıklıkla — İskelet kodunun da kendi kusurları vardır ve bir sürücüyü düzeltmek için harcanan zaman, modülü test etmek için harcanmayan zamandır.
Kodu anlamanız gerekiyor — Beyaz kutu yaklaşımı, modülü okuyamayan bir test uzmanının onun için anlamlı senaryolar tasarlayamayacağı anlamına gelir.

SSS

xUnit ailesi, sahte kodlar sağlayan taklit kütüphaneleri ve hangi yolların izlendiğini gösteren bir kapsama aracıyla birlikte çoğu dili kapsar. Seçim, test seviyesine değil, modülün diline göre yapılır.

Model, modülün kaynak kodunu okur, dalları numaralandırır ve her biri için, manuel geçişte sıklıkla gözden kaçan sınır değerleri de dahil olmak üzere bir durum önerir. RevOluşturulan durumlar, spesifikasyonun gerektirdiğinden ziyade kodun ne yaptığını ortaya koyduğu için inceleme gerekli olmaya devam etmektedir.

Evet, ve iskeleleme, bu tür yardımcıların en iyi performans gösterdiği yerdir, çünkü bir sürücü veya saplama, bilinen bir şekle sahip tekrarlayan koddur. Döndürülen değerler yine de insan kararı gerektirir, çünkü makul görünen bir saplama, aranan hatayı gizleyebilir.

Modüldeki her dalın ve her sınırın en az bir kez denenmiş olması yeterlidir. Yalnızca yüzde hedefi yanıltıcıdır, çünkü yüksek ifade kapsamı bile tüm karar sonuçlarının denenmemiş kalmasına neden olabilir.

Bir modül derlendikten sonra ve arayüzleri birlikte çalıştırılmadan önce gerçekleştirilir. Teslim edilen koda uygulanan ilk test seviyesidir; bu nedenle burada yakalanan hatalar entegrasyon veya sistem aşamalarına asla ulaşmaz.

Mevcut kodu takip edin. Yukarıdan aşağıya yaklaşım, kontrol mantığının önce yazıldığı ve alt modüllerin taslaklarının oluşturulduğu projeler için uygundur; aşağıdan yukarıya yaklaşım ise yardımcı modüllerin önce yerleştirildiği ve sürücülerin bunları çağırdığı projeler için uygundur.

Modül sorunsuz bir şekilde derleniyor, spesifikasyonu mevcut, bağımlılıkları ya mevcut ya da sahte olarak oluşturulmuş ve test verileri hazır. Spesifikasyon olmadan başlamak, alıştırmayı kodun bir açıklamasına dönüştürüyor.

Testler, bir modülün kusursuz olduğunu asla kanıtlayamaz, yalnızca denenen durumları başarıyla atlattığını kanıtlayabilir. Bu nedenle, modülü bozmaya çalışan test çalıştırmaları tasarlamak, başarılı olması beklenen test çalıştırmalarına göre daha fazla bilgi sağlar.