BE (CS) üzerinde çalışan bir öğrenciyim ve sorum şu:

1. Yazılım alanında test yapmak gerekli mi?
2. Dikkatli bir yazılım oluşturursak, neden test etmeliyiz?
3. Testlerden sonra olabilir emin biz yaptık çünkü bu hedefe (amaçlandığı şekilde ürün / yazılım işleri) elde ettik o test bunun için? Mümkün mü?

Sorum şu: Yazılımın test edilmesi gerekli mi?

Evet. Çünkü ne kadar iyi olursanız olun, her şeyi düşünemezsiniz.

• Ayrıca, yazılımınızdan, asla yapmak istemediğiniz şeyleri yapması istenecektir.
• Ayrıca , kodun kırılmadığından emin olmak için her türlü olasılığı düşünebileceğinizden bu kadar açık olan gereksinimleriniz asla olmayacak.
• Ayrıca, her zaman istendiği gibi çalışmayacak başkalarının yazılımı ve apisleriyle de çalışacaksınız, ancak “mükemmel” durumunuzda bir hataya yol açacağını ya da olması gerektiğini varsayacaksınız.

Evet

Aynı sebepten dolayı bir şef yemek yaparken de onun tadına bakmaktadır.

Böyle düşünen biriyle çalışıyorum, kodunu test etmesi gerekmeyen üst düzey bir programcı olduğu için düşünüyor. Şirket, bu tutumun ne kadar tehlikeli olduğunu anlamıyor ve onu düpedüz atmak yerine, hata biriktirme ile mücadele etmek için daha fazla programcı tuttu. Bu birikimin nereden geldiğini bilmeden, programlamanın neyle ilgili olduğunu düşünüyorlar. Temel olarak bu kipte çalışan 3 programcımız ve bu üçünün yarattığı hataları test edip düzeltmekten başka bir şey yapmayan 20 kişilik bir ekibimiz var.

OLMAYIŞ OF UYGUN TEST KILLS .

Bu nedenle, TANRI ya da tüm mükemmel bilen varlığın herhangi bir sürümü (şimdi bunu görmek isterdim) veya aktif olarak çok hızlı bir şekilde kovulmak istemediğiniz sürece, test etmeye başlamanızı şiddetle tavsiye ederim.

Yazılım insanlar tarafından yazılmıştır.

İnsanlar kusurludur ve hata yaparlar.

Bir teşebbüsün karmaşıklığı arttıkça, hataların, gözetimin veya unutulan şeylerin potansiyel sayısı (ve etkisi) artar - genellikle katlanarak.

Yani evet, test etmek gerekiyor. Denge ve bakış açısı getiriyor.

Dizüstü bilgisayarınızda kullandığınızı bildiğiniz bir işletim sistemi çalıştıran ve en sevdiğiniz renkte ölüm ekranını veren bir uçağa binecek misiniz? Bunu düşün.

Hiçbir kodlayıcı mükemmel değildir. Uzak, uzak, ondan gerçekten uzak. Teste ihtiyacınız var ve test ediciler sıklıkla geliştiricilerin eksik olduğu perspektifi (kullanım senaryoları olarak da bilinir) getirir.

Ne demek istediğimi bilmek için Google'daki en ünlü yazılım hatalarını araştırın.

Ve kolej düzeyinde, testlerin geliştirilmesi, birim testi ve çevik uygulamaların nerede olduğunu bilmek için biraz okuma yapın.

Test, gerçekten kullanılacak olan önemsiz (boyut veya işlev) uygulama için mutlak bir zorunluluktur. Testine gerek olmadığını söyleyen cevap verecek ve test etmenin önemini söyleyen (bu siteyi ziyaret ettikleri gibi) mesleğini önemseyen tek bir geliştirici bulamazsınız .

Önceden yayınlananlara ek olarak, herhangi bir uygulamada tam bir otomatik birim testi paketi olması gelecekteki kod değişikliklerinde size daha fazla güven verecektir. Bu daha yüksek güven (birim testleri BÜYÜK bir güvenlik ağı sağladığından) mevcut uygulamalarda daha hızlı kod değişikliklerine neden olacaktır (daha az geri izleme / çift kontrol nedeniyle)

Errare humanum est

Sorunsuz bir yazılım diye bir şey yoktur.

En yetenekli geliştirici hata kodunu yazar. Mükemmel bir geliştirici mevcut olsa bile, aşağıdakiler arasındaki tutarsızlıklar nedeniyle hala hatalar olacaktır:

• kullanıcı ihtiyaçları ve şartname belgeleri
• şartname ve tasarım
• Beklenen ve gerçek donanım ve yazılım ortamları
• dün ve bugün gerçek: yukarıda listelenen her şey, geliştirme sürecinin her aşamasında tam olarak bildirilmeyen değişikliklere tabidir.

Mükemmel geliştirici her şeyin sadece bir parçası. Ve mükemmel geliştiriciler yoktur.

Gerçek hayattaki programların çoğu:

a) çok sayıda dosyaya dağılmış yüzlerce kod satırı içerir;
b) birden fazla programcı tarafından geliştirilir;
c) geliştiricinin ortamından farklı ortamlarda kullanılır

Bu nedenle, programın gerçek hayatta nasıl çalıştığını kontrol etmezseniz, hiç çalışmadığı ihtimali% 100'e yakın olacaktır.

Diğer tüm mükemmel cevaplara ek olarak, kusursuz ve hatasız olduğunu bilseniz bile, gelecekte kodunuzla ilgilenmek zorunda olan diğer programcıları düşünün. Sizin gibi olduğunu bilmeyecekler ve bir değişiklik yaptıktan sonra hiçbir şeyi kırmadıklarından emin olmak için testlerinize güvenmek isteyecekler. Elbette bu, kodunuzu bir yıl içinde göremedikten sonra kendiniz için de geçerlidir!

EVET.

İşte henüz tam olarak ele alınmamış, biraz daha ince bir bakış açısı daha var:

Asla "bağımsız doğrulama" ihtiyacını küçümsemeyin . Bu, birkaç bağımsız editörün yayınlanmak üzere büyük bir yazı göndermeden önce çalışmanızı gözden geçirmesinin iyi bir nedenidir. Bir yazar ne kadar iyi olursanız olun, zaman zaman beyin fırtınası yapacaksınız - ve "bunun" yerine "bunun gibi" veya başka bir şey yazacaksınız. Kendinizi yeniden okuyorsanız, oldukça dikkatli bir şekilde bile, hala özlüyorsunuz, çünkü beyniniz düşünce sürecinizin akışını otomatik olarak doğru olarak kabul ediyor ve hatanın üstünden atlıyor. Yeni bir göze göre, bu tür bir hata genellikle göze batandır.

Programlamada aynı şeyi elde edersiniz: Kodunuzun ya da kendi kodunuzun temel "geliştirme testi" nizin doğru göründüğü bir akışa girmek oldukça kolaydır - çünkü bunu test ediyor ve belirli bir şekilde kullanıyorsunuz. Ama sonra başka bir çift el geldiğinde ve olayları biraz farklı şekilde veya sırayla tıklattığında, her şey çöküyor.

Şimdi, tabii ki, sen olabilir teoride resmen kodunuzda kendini her tek olasılık ve mantık dalı doğrulamanın yol gitmek, ama önemsiz olmayan yazılım için bu çok daha pahalı ve zaman alıcı başkasının patlama sahip olmaktan olacak sizin için kod. Ve muhtemelen hala hiç düşünmediğiniz şeyleri özleyeceksiniz.

Henüz dokunulmamış olan şey: kodunuz mükemmel olsa bile, hala güvende değilsiniz. Derleyiciler, mükemmel kodların bile derlemeden sonra yanlış davranmasına neden olabilecek hatalara sahiptir. İşletim sistemlerinde, çalıştırırken mükemmel bir ikili sistemin yanlış davranmasına neden olabilecek hatalar vardır. Donanımda sorunlara neden olabilecek hatalar vardır.

Bu yüzden bir makinede test yapmak ticari ürünler için yeterli değildir. Mümkün olduğu kadar vahşi ortamda karşılaşabilecekleri olası donanım ve yazılım kombinasyonları altında test edilmeleri gerekir.

Uzay mekiği için yazılımı yazan ekibin lideri, yazılımın mekiğe zarar vermeyeceğini belirtmek için her lansmandan önce uçtu.

Ona güvenmesi için ona ne verdi?

Sadece derleyerek ve kullanarak kodları sürekli test ediyorsunuz. Bazı IDE’lerde yazdıkça sağlık kontrolleri alıyorsunuz. Asla kodunuzu çalıştırmazsanız, test yapıyorsunuz.

Ne kadar çok test yaptığınız gerçekten bu tür bir sorunun temelidir ve bunun cevabı riske girer. Risk yönetimi açısından test etmenin ne kadar anlamlı olduğunu test edersiniz. Her şeyi veya hiçbir şeyi test etmek genellikle imkansızdır. Hiçbir şeyin yanında test etmek genellikle kötü bir hamledir. Aradaki her şey, risk seviyesine ve teslimatlarınızın maruz kalmasına bağlı olarak adil bir oyundur.

Bir ev ödevi sorusu gibi kokuyor.

Yazılım alanında test yapmak gerekli mi?

Evet. Kesinlikle. Bütün seviyelerde. Birkaç uzmanlık alanı dışında, kodumuzu belirli hatalara karşı (en azından makul bir zaman diliminde değil) doğru olarak matematiksel olarak ispatlayabileceğimiz bir aşamada değiliz; kırıldığı yer.

Dikkatli bir yazılım oluşturursak, neden test etmeliyiz?

Test sadece kodlama hatalarını bulmakla ilgili değildir. Ayrıca tüm gereksinimlerinizi yerine getirdiğinizden ve genel sistemin beklendiği gibi çalıştığından emin olmakla da ilgilidir. Başarısız bir işlemin belirli bir hata kodu döndürmesi gerekliliği varsa, hem işlevselliğin var olduğunu hem de doğru çalıştığını doğrulamak için bir test yazmam gerekir.

Tüm bunlar, şartnamenin ve tasarımın eksiksiz, doğru ve dahili olarak tutarlı olduğunu varsayar; bu genellikle böyle değildir. Eğer mektuba ilişkin şartnameye uysanız ve tasarımı son noktaya ve noktalı virgül sonuna kadar takip etseniz bile, teknik özellik veya tasarım kötüyse, entegrasyon zamanında problemler olacaktır. Genelde, sistem veya entegrasyon testi, şartnamenin kendisinin bir sorunlu olduğunu ve gözden geçirilmesi gerektiğini öğrendiğinizdedir (aşağıdaki savaş hikayesine bakın).

Testten sonra, bu amacı gerçekleştirdiğimizden (ürün / yazılım amaçlandığı gibi çalıştığından) emin olabileceğimizden emin olabilir miyiz? Mümkün mü?

Hayır,% 100’e değil. Akla gelebilecek her giriş veya uygulama yolu kombinasyonunu, en basit kod dışında test edemiyoruz. Tüm çevresel faktörleri hesaba katamayız. Tüm olası arıza modlarını hayal edemiyoruz.

Biz konum bir noktaya test edebilirsiniz makul herhangi bir büyük sorunlar olmadığından emin. Yine, bu yüzden her seviyede test etmemiz gerekiyor. Kodunuzun kenar koşullarını doğru şekilde işlediğinden emin olmak için bir testler takımı yazın (hatalı girdi, beklenmeyen sonuçlar, istisnalar vb.). Kodunuzun gereksinimlerini karşıladığını doğrulamak için birim testi. Uçtan uca işleme doğrulamak için sistem testi. Bütün bileşenlerin birbirleriyle doğru konuştuğunu doğrulamak için entegrasyon testi. Her şeyin müşterilerin sizi vurmak istemeyeceği şekilde çalıştığından emin olmak için kullanılabilirlik testi yapın.

Gerçek dünya senaryosu - Bazen bir GUI servisine güncellemeleri ekrana gelen bir tabloda görüntülemek üzere gönderen bir arka uç sistemi üzerinde çalışıyordum. Proje sırasında, ekrana filtreleme eklemek için bir gereksinim eklendi (örneğin, operatör tablodaki girişlerin bir alt kümesini görüntülemeyi seçebilir). Tasarım hata # 1 - filtreleme gerektiğini GUI hizmeti onlar haline gelmeden sorunları tanımak, fakat siyasete ve benim yetersizlik (Bu, ekran yönetimi fonksiyonları ekran yönetim yazılımı sorumluluğunda olması gerektiğini antikacı kavramı Mükemmel konumu var) tarafından yapılmıştır sorunlar , bu gereksinim arka uç hizmete verildi. Tamam, sorun değil, bunu yapabilirim. Durum değişikliklerini süzün, bir ileti alıyorum ve ardından için bir oluştur veya sil mesajı gönderiyorumtablodaki her satır , çünkü arayüz böyle çalışır (tasarım hatası # 2 - tek bir mesajda birden çok satıra güncelleme göndermenin yolu yoktur; tek bir "temizle" veya "sil" mesajı gönderemedik bile. tüm masa).

Eh, her şey gelişim sırasında iyi çalışır; ünite, sistem ve entegrasyon testleri doğru bilgileri gönderdiğimi ve filtre değişikliklerini doğru yaptığımı gösteriyor. Sonra kullanılabilirlik testine giriyoruz ve her şey çok düşüyor , çünkü veri hacmi çok zordu . Arka uç servisim ile GUI arasındaki ağ gecikmesi .15 ile .25 saniye arasındaydı. Sadece bir düzine satır için güncelleme göndermek zorundaysanız fena değil. Ölümcül birkaç yüz için güncellemeler göndermek zorunda kaldığınızda. Filtre durumunu değiştirdikten sonra GUI'nin donmakta olduğuna dair hata raporları almaya başladık; peki, hayır, olan şey, birkaç dakika beklemekti. Ekranı güncellemek için, çünkü her seferinde bir satır üst üste güncelleme protokolü gerçek bir senaryoyu idare edemedi.

Bunların hepsinin , en temel analizleri önceden yapmak için uğraşmamış olsaydık, ana müteahhitten herkes tarafından benim için küçük yaştan aşağıya kadar beklediğine ve olması gerektiğine dikkat edin. Teklif edeceğim tek savunma, altı ay süren bir projenin ikinci yılını teslimattan hemen sonra hurdaya çıkacak olmamızdı ve hepimiz bunun arkasını görmek için çaresiz kaldık.

Bu bizi test etmek için son nedene getiriyor - CYA. Gerçek dünya projeleri birçok nedenden dolayı başarısız olur, çoğu politiktir ve işler ters gittiğinde herkes iyi niyetle davranmaz. Parmaklar suçlamalar yapılmış olsun, sivri olsun ve günün sonunda size en azından gösteren bir kayda noktaya gerekiyor senin olması gerektiği kadar malzeme çalıştı.

Test her zaman yapılacak ve hatalar her zaman bulunacaktır. Sadece testlerin dahili olarak ekibiniz tarafından yapılması veya son kullanıcının test cihazı olması. Son kullanıcı tarafından bulunan bir hatanın maliyeti, test sırasında tespit edilenden çok daha yüksektir.

İyi bir Hata Toleranslı Bilgi İşlem kursu almanızı öneririm. Dikkatli yazılım tasarımı, yazılım ürününüzde sağlamlığa ulaşmanın temellerinden yalnızca biridir. Diğer iki sütun yeterli test ve gereksiz tasarımdır. Temel amaç, üssel bir sayıda bilinmeyen başarısızlık koşulunu barındırmak ve bilinenlerden bazılarıyla ilgilenmeyi önceliklendirmektir:

1.) tasarım ve uygun uygulama sayesinde olası birçok başarısızlığı ortadan kaldırın 2.) tasarım aşamasındaki beklenmeyen hataları ve çeşitli uygulama biçimleriyle yanlış uygulamalardan kurtulun (ünite, entegrasyon, rastgele) temporal => yeniden hesapla, yeniden dene veya ara = => kopya tut, parite)

Test aşamasını ortadan kaldırırsanız, kendinizi başarısızlıkları ele almak için yalnızca tasarım ve artıklık aşamaları ile terk edersiniz.

Ayrıca, ürün açısından, paydaşlarınız (örneğin yönetim, kullanıcılar, yatırımcılar), ürününüzün belirli kalite ve güvenlik şartnamelerini, kriterlerini vb. Karşıladığı konusunda bir güvence isteyecektir. Bunların dışında, yazılımı test etmediniz. 'akıl sağlığı kontrolü' için sadece yaptırdınız mı? Tüm bu nedenler yazılım testlerini daha çekici kılmaktadır.

Tüm programların en azından başlaması gereken hatalar var.

Her beş satır test edilmemiş kod başına yaklaşık 1 hata üzerinde yakınsak bazı çalışmalar yapılmıştır.

Bir tarih dersi:

1960'larda IBM'in bir "NOP" programına ihtiyacı vardı, böylece JCL'de bir program çalıştırmadan bazı işlevleri yerine getirebiliyorlardı. Geliştiriciler, kodun tamamını "IEFBR14" adı altında içerdiği tek satırlık bir montaj programı ile geldi:

       BR 14 * brach to return address in register 14

Uzun süren bu süre boyunca, bu bir program 2 hata raporuna ve beş değişikliğe tabi tutulmuştur.

Ünite testlerinde kod yeniden düzenleme işlemi gerçekten daha hızlı. Bir birim testi ayrıca size somut fonksiyonun basit kullanımını gösterir, böylece programcıların tüm kodu tam olarak bilmediği büyük projelerde gerçekten yararlı olabilecek küçük bir "howto" vardır.

TDD (Test odaklı geliştirme) ile geliştirirken, gereksiz alıcı / ayarlayıcılara vb. Sahip değilsiniz. Sadece ihtiyacınız olanı yaratırsınız.

Cevaplamak için 3. Sorunuzu:

Bir programcı ve bir yazılım testçisi olmuş, evet, test sırasında yazılımın gereksinimlerini karşıladığınızdan emin olabilirsiniz.

{QA şapkasını takma}

Nasıl? Bunu testlerinizi test kodundan kabul kriterlerine, kabul kriterlerine ve özelliklere göre izleyerek yapabilirsiniz. Tasarım zincirindeki her bir testi izlerseniz ve bir veya daha fazla gereksinime eşlerlerse, kodunuzun gereksinimlerini karşıladığından emin olmak için testlerinizin kullanıldığından emin olabilirsiniz (bu yeterli bir test kapsamı kavramını ortaya çıkarsa da başka bir konu). Tasarım zincirinin bir testini izleyemiyorsanız, muhtemelen gerekmeyen şeyleri test edersiniz ve bu zaman kaybıdır. Kabul kriterleri ayrıca istenmeyen davranışların kontrol edilmesini de içerebilir - sizi de sınayabilir, bu sayede kalite sürümüne bir adım daha yaklaşabilirsiniz.

{QA hat kapalı}

Hiçbir kod hiçbir zaman hatasız değildir, geliştirme sırasında kalitesini değerlendirmek için daha fazla çaba harcandığında zamanla daha az maliyetlidir.

3 senedir Yazılım testcisiyim. Başlangıçta kendim test etme konusunda şüpheliydim, çünkü geliştirme departmanı ve proje yönetimi işlerini yaparsa yazılımda hatalar olmamalıydı.

AMA bu durum böyle değil. ++++++++

Hatalar sıklıkla meydana gelir, bazıları bir projenin çalışması için kritik öneme sahiptir. Ayrıca tarayıcılar arası testler de var (SAFARI, FIREFOX, CHROME ve Internet Explorer gibi mevcut farklı tarayıcılarda test anlamına geliyor) ve sadece tüm tarayıcılarda çalışmayan bir anket penceresinde YES ve NO gibi basit arayüz düğmelerinin bulunduğu projede çalıştım. bazıları.

İnternet sayfası testi üzerinde çalıştım ve basit METİN DEĞİŞİKLİKLERİNİ test ediyordum ve kendime bu basit işte hiç bir kusur olamayacağını, ancak olamayacağını düşündüm.

Ayrıca, yeni geliştiricilerin takıma ne zaman katıldığı ve mevcut karmaşık bir internet başvuru formu için harici sayfalara bağlantı / çağrı içeren bir güncelleme çalışması verildiğini, eski ve yeni geliştiriciler arasındaki iletişimin yetersizliğinden dolayı hata oluştuğunu gördüm. çeşitli sebeplerden dolayı (eğitmek için zaman yok, eğitmek için irade yok vb.)

EVET

Yazılımınızın yalnızca mantıksal bir işlev olduğunu VE (b1, b2) burada b1 ve b2'nin sadece bit olduğunu hayal edin. Bununla birlikte, çevrenizdeki ortam tam olarak belirtilenleri sağladıysa, yazılımınızın hatasız olduğundan emin olmak için 4 test senaryosuna ihtiyacınız vardır.

Şimdi sisteminiz, en basit olanı bu mantıksal işlevden çok daha karmaşık olan birçok işlevden oluşur. Hatasız olduğundan nasıl emin olabilirsiniz?

(devam edecek)