Yazılım Testine Giriş (Ammann & Offutt) s.32 5 seviyeli bir test olgunluk modelinde bahseder:
Seviye Test etme ve hata ayıklama arasında fark yoktur.
Seviye 1 Testin amacı yazılımın çalıştığını göstermektir.
Seviye 2 Testin amacı yazılımın çalışmadığını göstermektir.
Seviye Testin amacı belirli bir şeyi kanıtlamak değil, yazılımı kullanma riskini azaltmaktır.
Seviye 4 Test, tüm BT profesyonellerinin daha kaliteli yazılım geliştirmesine yardımcı olan zihinsel bir disiplindir.
Her ne kadar daha fazla ayrıntıya girmeseler de. Hata ayıklama ve test arasındaki farklar nelerdir?
Test, koddaki hataları veya farklı bir açıdan, programın yapması gereken şeyi yaptığını uygun bir seviyeye (asla% 100 olamaz) kanıtlamak içindir. Manuel veya otomatik olabilir ve birim, entegrasyon, sistem/kabul, stres, yük, ıslatma vb. Testler gibi birçok farklı çeşidi vardır.
Hata ayıklama, programdan belirli bir hatayı bulma ve kaldırma işlemidir. Tüm hatalar farklı olduğu için her zaman manuel, tek seferlik bir işlemdir.
Benim tahminim yazarın, Seviye 0'da, testin gerçekten test edilen özelliği iyice test etmesini sağlamak için bir test planı veya herhangi bir şey olmadan, sadece manuel olarak, geçici bir şekilde yapıldığı ve testlerin yapılabileceği anlamına gelir. güvenilir bir şekilde tekrarlanır.
Hata ayıklama, ilgili, yapılandırılmamış ve güvenilir olmayan adım adım manuel bir işlemdir. Hata ayıklama yoluyla test ederek tekrarlanamayan senaryolar oluşturursunuz, bu nedenle regresyon testi için işe yaramaz. 0 dışındaki tüm düzeyler (örneğin), bu nedenle hata ayıklamayı hariç tutuyor.
Hata ayıklama, yöntemsel olarak kodun üzerinden geçerek bilinen ve bilinmeyen sorunları gidermeye yönelik bir girişimdir. Hata ayıklama yaparken, genellikle bir bütün olarak koda odaklanmazsınız ve neredeyse her zaman arka uçta, gerçek kodda çalışırsınız.
Test, daha sonra hata ayıklanabilecek kodu kullanmanın çeşitli yollarıyla bir sorun yaratma girişimidir. Neredeyse her zaman kodu son kullanıcının çalıştıracağı şekilde çalıştırdığınız ve kırmaya çalıştığı kullanıcı alanında yapılır.
Basit bir ifadeyle, programınız, yürütme sırasında olması gerektiği gibi davranmadığında bir "hata" oluştuğu söylenir. Yani beklenen çıktıyı veya sonuçları üretmez. Bu hatanın kaynağını bulma, davranışı düzeltmenin yollarını bulma ve sorunu düzeltmek için kodda veya yapılandırmada değişiklik yapma girişimleri hata ayıklama olarak adlandırılabilir.
Test, programın veya kodun farklı koşullar altında doğru ve sağlam bir şekilde çalıştığından emin olduğunuz yerdir: Girişler, standart doğru girişler, bilerek yanlış girişler, sınır değerleri, değişen ortam (OS, yapılandırma dosyası) sağlayarak kodunuzu "test edersiniz" . Temel olarak, hataları keşfetmeye çalıştığınızı ve sonunda test sürecinde "hata ayıkladığınızı" söyleyebiliriz. Umarım yardımcı olur.
Hiç yok. Doğru yaparsanız:
Regresyon Testi ve Saf Sıkma
Kent Beck, Three Rivers Enstitüsü
Özet: Bir arızayı etkin bir şekilde izole etmek için, sistem düzeyinde bir testle başlayın ve arızayı gösteren mümkün olan en küçük teste ulaşıncaya kadar aşamalı olarak satır içi ve Prune yapın.
Test, müşteriye salıvermeden önce hoşlandığınız bir ayrıcalıktır.
Hatalar, müşteriye bıraktıktan sonra katlandığınız bir kabus.
Diğerleri test ve hata ayıklama arasında farklılıklar nelerden bahsetmiştir.
Bir ortak bölümünü vurgulamak istiyorum. Bir test cihazı bir kusur bulduğunda, izole edilmelidir. Hata ayıklama, sorunu izole etme tekniklerinden biridir ve uygulama durumunu ve çalışma zamanında kodunu analiz ederek temel nedenleri bulur. Aslında, hata ayıklama Oxford Sözlükler tarafından " tanımlama tanımlama ve bilgisayar donanımından veya yazılımından hataları çıkarma işlemi" olarak tanımlanır.
İster bir test cihazı ister geliştirici olsun, bir kusuru kim izole edecek (veya özellikle hata ayıklayacak) ikincil bir sorudur.
Hatalar görünür hatalardır. Hata ayıklama, test durumu tasarımından sonra başlatılan işlemdir. Testten daha zor bir iştir, çünkü hata ayıklama işleminde hatanın kaynağını bulmamız ve kaldırmamız gerekir, bu nedenle bazen hata ayıklama kullanıcıyı hayal kırıklığına uğratır.
Listelediğiniz test olgunluğu modeli, geliştirme ekibinin zihniyetinin tanımlarıdır.
Listenin açıkça ifade etmediği, zihniyetteki değişimin testin yürütülme şeklini nasıl etkilediğidir.
Bir geliştirme ekibi bir sonraki seviyeye ilerledikçe, testin kapsamı genişletilir.
Seviye 0'da test yapılmaz, çünkü takım gerekli olmadığını düşünür.
Seviye 1'de, temel işlevlerin nominal bir kapsamını sağlamak için test yapılır.
Seviye 2'de, test Seviye 1'deki her şeyi içerecek şekilde genişletilir ve yıkıcı testlere eklenir (kaynak kodu ve ikili dosyalar dahil olmak üzere geliştiricilerin erişebildiği tüm bilgilere erişimi olan özel bir test ekibi ve olabilecek hataları bulmaya çalışır) bir kullanıcı rolünden tetiklenir)
Seviye 3'te Seviye 1-2'deki her şeye ek olarak fonksiyonel olmayan tabanlı test/doğruluk tabanlı olmayan test (performans özellikleri gibi) eklenir.
Seviye 4'te, yazılım testinin amaçları, müşteriye dönük BT personeli de dahil olmak üzere herkes tarafından iyi anlaşılmıştır. Böylece, BT personeli hangi senaryoların test edileceği hakkında geri bildirimde bulunarak Seviye 4'ün risk kapsamını geliştirebilecektir.
(Feragatname: Ders kitabına erişimim yok, bu nedenle terminolojim yanlış olabilir.)
Günlük, pratik terimlerle konuşursak, tamamen düşünüyorum bağlama bağlıdır.
Orta-büyük bir ekipte, yüksek/çok yüksek standartlarda (bankacılık, askeri, büyük ölçekli, yüksek bütçeli veya iş açısından kritik sistemleri düşünün) çalışmak, o zaman açıkça düşünüyorum "hata ayıklama" "testin sonucu olmalı" ve bunlar açıkça çok farklı şeyler. İdeal olarak test, hata ayıklamaya (bir hazırlama ortamında) yol açar ve üretimde ikisinden birine sıfır gerekir.
Test kapsamı geniştir, düzenli ve çok resmidir - hata ayıklama, belirli bir arızayı düzeltmeye ihtiyaç duyulduğunda zaman zaman meydana gelen belirli bir süreçtir - bu açık değildir ve bir sistemin işleyişi ve sonuç çıktılarının daha derin bir incelemesini gerektirir.
Burada aklımda test yapmak önemli bir şeyken, hata ayıklama sadece bir başarısızlığın çözümü opak olduğunda gerekli olan özel bir araçtır.
Büyük takımlar ve/veya sistemler için TDD'de bariz fayda tamamen "buggy" olarak göze alamayacağımı tamamen anlıyorum. Ayrıca, karmaşık (genellikle "arka uç") sistemler için veya kodda çıktıya kıyasla yüksek oranda karmaşıklık olması durumunda çok mantıklıdır. Daha sonra "test etme" işleminin, hataların ne zaman ve neden oluştuğunu bildirme konusunda gerçekçi bir şansı vardır. Çok karmaşık işler yapan veya açıkça ölçülebilir çıktılarla sonuçlanan sistemler genellikle kolaylıkla test edilebilir ve bu nedenle testler hata ayıklamadan farklıdır. Bu gibi durumlarda testler, beklentilerle fiili çıktıların eşleşmesini doğrulamak veya onaylamamak için prosedüre dayalı, resmi bir yöntem gerektirir. Test her zaman gerçekleşir ve zaman zaman hata ayıklama ihtiyacını bize bildirir.
Bu her yerde bulunan bir gerçek olsaydı çok güzel olurdu, dev döngülerim açıkça tanımlanmış ikili çıktı (kırmızı, yeşil) ile sınırlandırılmış olsaydı çok isterdim ama ...
Benim durumumda (kuşkusuz özel - küçük orta ölçekli, yetersiz finanse edilmiş web tabanlı, veri odaklı kurumsal yönetici sistemlerinde% 98 yalnız çalışmak) TDD'nin bana nasıl yardımcı olabileceğini gerçekten göremiyorum! Daha doğrusu "hata ayıklama" ve "test etme" hemen hemen aynıdır.
Esas olarak, "test" teriminin kullanımı TDD metodolojisi ile ilgilidir/yakından ilişkilidir.
Bu bir tamamen, tamamen Zeitgeist un "Söylemeyenlere inan, shun, shun", despicly serin olmayan bir şey söylemek. Ama bağlamımı düşünerek, pratik bir şapka ile belirsiz bir şekilde bile değilim, en vahşi hayal gücümde TDD'nin müşterilerime para için daha fazla değer sunmama nasıl yardımcı olabileceğini görün.
Ya da daha doğrusu, "test etmenin" resmi bir kod temelli süreç olduğu ortak varsayımına kesinlikle katılmıyorum.
Temel itirazım (benim özellikle * bağlamında *) ...
Güvenilir bir şekilde çalışan kod yazamıyorsam - o zaman cehennem Ben test güvenilir bir şekilde çalışan kod yazmam gerekiyordu kodu.
Benim için hiç bir örnek görmedim ya da (benim özel bağlamda) beni rahatsız etmem için beni yeterince heyecanlandırdı düşünme hakkında tek bir test yazma, yapabildim şu anda bazı gülünç derecede önemsiz test kodları yazıyor olabilirim, belki de "depom tam olarak - ve sadece - istediğimde Name == X olan bir Kullanıcı varlığını döndürüyor mu?" belki-the-internet-gerçekten-sadece-saf-aptal-spouting-kendini-tatma-çılgınca-az-bilgili-kan-kaynarlyignorant-savurgan-aptal çöp, ama ben sadece şeytanın savunucusu oynama ihtiyacını hissediyorum. (Birisinin bana ışığı göstermesini ve beni dönüştürmesini umuyorum, belki bu müşterilerime para için daha iyi değer verir mi?).
Tartışmalı olarak "hata ayıklama" bazen "test" ile aynıdır. Bununla, günlük çalışma hayatımda, zamanımın en az üçte birini farklı tarayıcılarda sistemimin yerel sürümü ile oynayarak, işimi kırmak ve sonra araştırmak için çaresizce çeşitli farklı tuhaf şeyler denemek için harcadığımı gerçekten kastediyorum. başarısız olmasının nedenleri ve düzeltilmesi.
Ben% 100 TDD mantra "kırmızı/yeşil/refactor" bariz yarar katılıyorum, ama benim için (düşük med bütçe, solo dev RIA arazi çalışma) Gerçekten bana nasıl olabileceğini göstermek için gerçekten isterim muhtemelen, mantıklı ve hayati önemle gerçekçi olarak herhangi bir ek değer elde edin daha fazla yazarak (sadece potansiyel olarak kusurlu test kodu) aslında gerçek insan etkileşimlerine bağlı olan çabalarımın tam (ve esasen sadece) çıktısıyla etkileşime girmekten daha fazla.
Benim için geliştiriciler "test" hakkında konuştuğunda, bu genellikle TDD anlamına gelir.
Testler varmış gibi kodlamaya çalışıyorum, tüm bu test odaklı geliştirmenin teşvik ettiği tüm desen/uygulamalar ve trendlerin harika ve güzel olduğunu düşünüyorum, ancak benim için küçük dünyamda "test" daha fazla kod yazmıyor, aslında gerçek dünyayı test etmek, onu gerçekçi bir şekilde ortaya çıkarır ve bu, hata ayıklama ile hemen hemen aynıdır veya buradaki aktif değişiklik, insan, çıktı merkezli otomatik olmayan "testlerin" doğrudan bir sonucu olan "hata ayıklama" dır. Bu, otomatik ve biçimsel bir şey olarak "test etme" ve insani ve geçici veya yapılandırılmamış bir şey olarak "hata ayıklama" görüşünün aksine.
Hedef gerçekten para/çaba için değerse ve web tabanlı etkileşimli uygulamalar yapıyorsanız, çabanın çıktısı web sayfalarıdır ve çok temelde insan girişine nasıl tepki veriyorlar - yani " test etmek "en iyi şekilde bu web sayfalarını gerçek insan etkileşimi aracılığıyla test ederek elde edilir. Bu etkileşim beklenmedik veya istenmeyen çıktılara yol açtığında "hata ayıklama" meydana gelir. Hata ayıklama, program durumunun gerçek zamanlı denetimi fikriyle de yakından ilgilidir. Testler genellikle talihsiz bir ilişki olduğunu düşündüğüm otomasyonla ilişkilidir.
Hedef gerçekten çaba için değerse ve otomatik test etkili ve son derece faydalıysa, hata ayıklama sadece bu testin bir çıktısı veya otomatik testin zayıf bir alternatifi ise, neden dünyanın en çok ziyaret edilen ikinci web sitesi (Facebook) ) sık sık körü körüne belirgin (kullanıcılar için, ancak test ekibi ve test kodu açıkça değil) hataları ile bilmece?
Belki de güven verici yeşil ışıklara odaklandıkları ve işlerinin çıktılarını gerçekten kullanmayı unuttukları için mi?
Çok fazla geliştirici, testin kodla yaptığınız bir şey olduğunu düşünüyor mu ve hata ayıklama, zaman zaman IDE ile bir simge kırmızıya döndüğünden ve nedenini çözemediğinizden) yaptığınız bir şey mi? beklentiler ve çıktılar arasındaki boşlukları kapatmak için odaklanmamız gereken şeylerin pratik gerçekliğini gizleyen, onlarla ilişkili talihsiz değer yargılarına sahiptir.