Test. Temel teori

Duman ve sıhhi testler projenin bir sonraki versiyonunun yayınlanmasının hemen ardından başlıyor. Birçok genç testçi için bu süreç tam bir kaos gibi görünüyor. Kendinizi tanıyor musunuz? O halde bu yazı tam size göre. Şimdi duman testi ve sıhhi testlerin tanımlarına bakacağız ve aralarındaki farkları anlaşılması kolay örneklerle göstereceğiz.

Duman Testi:

Ortaya çıkan yapının teste uygun olduğundan emin olmak için duman testi yapılır. Buna “sıfır gün” doğrulaması da denir.

Bu tür testler zaman kaybetmenizi önleyecektir. Temel özelliklerle ilgili sorunlar varsa ve kritik hatalar giderilmemişse, uygulamanın tamamını test etmenin bir anlamı olmaması mantıklıdır.

Sıhhi testler:

Uygulamanın temel işlevselliğini kontrol etmek için yayın aşamasında sıhhi testler gerçekleştirilir. Genellikle daha ileri gitmezler. Bu teste bazen regresyon testinin kısaltılmış versiyonu denir.
Yayınlanma tarihleri ​​kısıtlı olduğunda kapsamlı regresyon testi yapmak neredeyse imkansızdır. Bu durumda uygulamanın ana işlevlerinin çalışmasını kontrol eden sıhhi testler harika bir iş çıkarıyor.

Duman ve hijyen testleri arasındaki farkı daha iyi anlamak için bir örnek:

İlk sürümün planlandığı bir proje var. Geliştirme ekibi yapıyı test için yayınlar ve test ekibi çalışmaya başlar. İlk test yetenek testidir. Bu sürümle çalışıp çalışamayacağınızı öğrenmeniz gerekiyor. Bu duman testidir. Ekip, yapı üzerinde daha fazla çalışma yapılmasına onay verirse, testin daha derin aşamalarına gönderilir. Derlemenin üç modülden oluştuğunu düşünelim: “Giriş”, “Yönetici” ve “Çalışan”. Test uzmanlarından oluşan bir ekip, ayrıntılara girmeden her modülün yalnızca temel işlevlerinin işlevselliğini kontrol eder. Bu sıhhi test olacak.

Duman ve hijyen testleri arasındaki birkaç fark daha:

• Duman testi hem geliştiriciler hem de test uzmanları tarafından gerçekleştirilir;
• Sıhhi testler yalnızca test uzmanları tarafından yapılır.

• Duman testi, uygulamanın baştan sona tüm temel işlevlerini kapsar;
• Temizlik testi uygulamanın yalnızca belirli bir bileşenini test eder.

• Duman testi hem kararlı hem de dengesiz yapılardan geçer;
• Yapının nispeten kararlı bir versiyonu sıhhi testlerden geçiyor.

Kirill Flyagin, oyun tasarımcısı, QA Lideri

Bu tür testlerle bir yaz benzetmesi yapalım. Diyelim ki bir karpuz satın almak istiyorsunuz. Duman testi, görsel olarak kontrol ettiğiniz, şeritlere baktığınız, sıktığınız, vurduğunuz ve değerlendirdiğiniz zamandır. Bu şekilde gerçekten lezzetli meyveler almayı başaran ustalar var. Hijyen testinde, tepeden bir piramit kesersiniz ve rengini (bileşenlerden biri olarak) kontrol edersiniz, ancak karpuzun tamamının böyle olup olmadığını hiçbir şekilde bilemezsiniz. Ancak kesim kısmına tamamen güveniyorsunuz.

Tek bir dosyadan oluşan basit bir bilgisayar programı oluşturmak istiyorsanız, yazdığınız tüm kodları toplayıp o dosyaya bağlamanız yeterlidir. Bir geliştirme ekibinin üzerinde çalışacağı tipik bir projede yüzlerce, hatta binlerce dosya olacaktır. Bu, yürütülebilir bir program oluşturma sürecinin giderek daha karmaşık ve zaman alıcı hale gelmesine "katkıda bulunur": programı çeşitli bileşenlerden "bir araya getirmeniz" gerekir.

Örneğin Microsoft ve diğer bazı yazılım geliştirme şirketlerinde kullanılan uygulama, günlük olarak duman testiyle desteklenen bir program oluşturmaktır. Her gün, her dosya bir araya getirildikten, bağlandıktan ve yürütülebilir bir programda birleştirildikten sonra, programın kendisi oldukça basit bir dizi teste tabi tutulur; bunun amacı, programın çalışma sırasında sigara içip içmediğini görmektir. Bu testlere duman testleri denir (İngiliz dumanından - dumandan). Çoğu zaman, bu süreç oldukça iyi bir şekilde otomatikleştirilmiştir (ya da öyle olmalıdır).

AVANTAJLARI. Bu basit süreç birçok önemli fayda sağlar.

Entegrasyon sırasında riski en aza indirme

Bir geliştirme ekibinin karşılaştığı en önemli risklerden biri, geliştiricilerin kod üzerinde birbirlerinden bağımsız olarak ayrı ayrı çalışmaları ve bunun sonucunda üretim kodu birleştirildiğinde karmaşık bir programın beklendiği gibi çalışmamasıdır. Projedeki uyumsuzluğun ne zaman keşfedildiğine bağlı olarak, özellikle program arayüzü değiştiyse veya programın önemli bölümlerinde büyük değişiklikler yapıldıktan sonra programda hata ayıklamak daha önceki entegrasyona göre daha uzun sürebilir.

Duman testlerinin günlük olarak toplanması ve çalıştırılması, entegrasyon hataları riskinin azaltılmasına, bunlara zamanında yanıt verilmesine ve bunların birikmesinin önlenmesine olanak sağlar.

Düşük kaliteli yazılım ürünü riskinin azaltılması

Ürünün kalitesinin düşük olması doğrudan entegrasyon sırasındaki arızalara ve sorunlara bağlıdır. Günlük olarak minimum sayıda duman testi yapılması, hataların ve sorunların projeyi ele geçirmesini önler. Bir projeyi bir kere stabil hale getirdiyseniz sonsuza kadar stabil kalacaktır. Bu şekilde kalitenin hataların meydana geldiği seviyeye düşmesine asla izin vermeyeceksiniz.

Hataların teşhisinde yardım

Eğer bir gün ürün oluşmazsa (hatalarla oluşuyorsa), o zaman günlük olarak bir dizi duman testi oluşturup çalıştırarak sorunun nedenini bulmak çok daha kolaydır. Dün çalışan ve bugün çalışmayan bir ürün, iki yapı arasında bir sorun olduğuna dair açık bir ipucudur.

İyileştirilmiş moral

Ürün çalışırsa ve her geçen gün daha fazla yeni nitelik ve işlev kazanırsa, teoride geliştiricilerin morali artmalıdır ve bu ürünün tam olarak ne yapması gerektiği kesinlikle önemli değildir. Ürün ekranda bir dikdörtgen gösterse bile, bir geliştirici için "beyin çocuğunun" çalışmasını izlemek her zaman bir zevktir :)

Günlük yapıları ve duman testlerini kullanma

İşte bu prensibin bazı detayları.

Günlük uygulama oluşturma

Günlük montajın temel bir kısmı, en son tamamlanan parçanın montajıdır. Dynamics of Software Development'ta (Microsoft Press, 1995) yazan Jim McCarthy, bir projenin günlük olarak oluşturulmasını projenin kalp atışı olarak nitelendirdi. Kalp atmıyorsa proje yok, ölü. Daha az mecazi anlamda, Michael Cusumano ve Richard W. Selby, günlük binayı projenin senkronize edici dürtüsü olarak tanımladılar (Microsoft Secrets, The Free Press, 1995). Her geliştirici kodu kendi yöntemiyle yazar ve kod, proje için genel kabul görmüş çerçevenin ötesine geçebilir - bu normaldir, ancak senkronizasyon darbesine her maruz kaldığında kod standarda geri döner. Senkronizasyon darbesini sürekli kullanarak geliştirme konusunda ısrar ederek projenin tamamen senkronizasyon dışına çıkmasını engellersiniz.

Bazı şirketlerde her gün değil haftada bir proje oluşturmak gelenekseldir. Bu sistem yanlış çünkü... Bu hafta projede bir "arıza" olması durumunda, bir sonraki başarılı inşaata kadar birkaç hafta daha geçebilir. Bu durumda firma günlük proje montaj sisteminin tüm faydalarını kaybeder.

Başarısız derleme kontrol ediliyor

Günlük proje oluşturma durumunda projenin çalışması gerektiği varsayılır. Ancak projenin işe yaramadığı ortaya çıkarsa, bunu düzeltmek 1. önceliğe sahip bir görev haline gelir.

Her projenin kendine has standardı ve “montaj sırasında kırılma” denilen durumun işareti vardır. Bu standart, küçük kusurları takip etmek ve projeyi "engelleyen" kusurları gözden kaçırmamak için yeterli bir kalite düzeyi belirlemelidir.

İyi bir yapı en azından aşağıdakilere sahip olandır:

• tüm dosyalar, kitaplıklar ve diğer bileşenler başarıyla derlendi;
• tüm dosyalara, kitaplıklara ve diğer bileşenlere olan bağlantılar geçerlidir;
• uygulama programının doğru çalışma olasılığını dışlayan herhangi bir kararlı sistem hatası içermemektedir;
• Tüm duman testleri başarılıdır.

Günlük duman testleri

Duman testleri baştan sona projenin tamamında yapılmalıdır. Kapsamlı veya kapsamlı olmaları gerekmez, ancak tüm temel işlevlerin testini içermelidirler. Duman testi yeterince derin olmalıdır ki, eğer başarılı olursa, proje istikrarlı olarak adlandırılabilsin ve daha derin testlere tabi tutulabilecek bir proje olarak adlandırılabilsin.

Duman testi yapılmazsa günlük montajın anlamı kaybolur. Bu işlem ürünün kalitesini korur ve herhangi bir entegrasyon sorununa izin vermez. Bu olmadan, amacı derlemeyi kontrol etmek olan günlük derleme süreci zaman kaybıdır.

Duman testi projeyle aynı seviyede geliştirilmelidir. Başlangıçta duman testleri, bir projenin "Merhaba Dünya!" mesajı üretip üretemeyeceği gibi basit bir şeyi kontrol edecektir. Sistem geliştikçe duman testleri daha derinlemesine hale gelir. İlk duman testi için harcanan süre birkaç saniye içinde hesaplanır ancak sistem büyüdükçe duman testi için gereken süre de artar. Bir projenin sonunda duman testi saatlerce sürebilir.

Yapı grubu tanımlama

Çoğu projede sistemin günlük yapısını gözden geçirmekten ve duman testlerini yapmaktan sorumlu belirli bir kişi vardır. Bu iş, bu çalışanın görevlerinin bir parçasıdır, ancak büyük projelerde bu tür çalışanlardan daha fazlası olabilir ve bu tür işler onların ana sorumluluğudur. Örneğin, Windows NT 3.0 proje oluşturma ekibinde dört kişi vardı (Pascal Zachary, Gösteri durdurucu!, Özgür Basın, 1994).

Bir yapıya yalnızca anlamlı olması durumunda revizyon ekleyin

Tipik olarak bireysel geliştiriciler, sisteme günlük olarak anlamlı değişikliklerin eklenmesine izin verecek kadar yavaş kod yazar. Birkaç günde bir kodun büyük bir kısmı üzerinde çalışıp onu sisteme entegre etmeleri gerekiyor.

Çoğu projede bir sonraki yapının piyasaya sürülmemesi durumunda para cezası sistemi vardır. Bir projenin en başında, çalışma tasarımının sürdürülmesinin en yüksek öncelik olduğunu açıkça belirtmekte fayda var. Bir sonraki yapının yayınlanmaması bir istisna olabilir ancak kural değildir. Geliştiricilerin, sistem yeniden çalışana kadar her şeyi bırakmaları konusunda ısrar edin. Sık sık inşaat arızaları durumunda (çalışmayan bir yapının serbest bırakılması), projeyi normale döndürmek oldukça zordur.

Küçük cezalar, sistem oluşturma kalitesinin izlenmesine yönelik yüksek düzeydeki ihtiyacı vurgulamaktadır. Bazı projelerde, montajın başarısız olduğu geliştiricilere, bozuk montajı serbest bırakmaları için lolipoplar verilir. Böyle bir geliştiricinin ofisinin kapısında, montajı düzeltene kadar ilgili bir işaret asılı kalır (geliştiricilerin ayrı ofisleri olması şartıyla :)). Diğer projelerde suçlu geliştiricilerin sahte keçi boynuzu takmaları veya bir “moral fonuna” (gerçek şirket geçmişinden alınan örnekler) belirli bir miktar katkıda bulunmaları gerekiyor.

Ancak bazı projelerde daha ciddi cezalar uygulanıyor. Örneğin, yüksek öncelikli projelerde (Windows NT, Windows 95, Excel) çalışan Microsoft geliştiricileri çağrı cihazları kullanıyordu ve bir denetim tespit edilirse işe rapor vermeleri gerekiyordu. Gece 3'te bir arıza veya hata keşfedilse bile.

Sistemi monte edin ve basınç altında bile "tütsüleyin"

Bir projenin yayınlanma programının baskısı arttığında, sistem yapısını her gün kontrol etme işi zaman kaybı gibi görünebilir. Ancak bu doğru değil. Stresli durumlarda geliştiriciler sıklıkla hata yapar. Normal şartlarda var olamayacak uygulamaları yayınlama konusunda baskı hissediyorlar. Kodlarını birim testlerle normalden çok daha az dikkatli kontrol ediyorlar. Bu gibi durumlarda kod, daha az stresli durumlara göre çok daha hızlı bir entropi durumuna girme eğilimindedir.

Bu süreçten kimler yararlanıyor? Bazı geliştiriciler günlük inşaatlara karşı protesto yapıyor ve protestolarını bu aktivitenin pratik olmaması ve büyük zaman yatırımı ile meşrulaştırıyor. Ancak son zamanlarda tüm karmaşık sistemler günlük montaj ve duman testlerine tabi tutulmuştur. Microsoft Windows NT 3.0 piyasaya sürüldüğü sırada 40.000 dosyada 5,6 milyon satır içeriyordu. Yapımın tamamı 19 saat sürdü ve birden fazla bilgisayarda gerçekleştirildi. Buna rağmen geliştiriciler sistemi her gün birleştirmeyi başardılar. Profesyonel bir ekip olarak NT geliştirme ekibi başarısının çoğunu günlük yapısına borçludur. Daha az karmaşık projeler üzerinde çalışan ve bu nedenle günlük yapım sürecinden yararlanmayan geliştiriciler, bazı makul açıklamalar bulmayı düşünmelidir.

Duman Testi Nedir?

Duman testi, dağıtılan yapının kararlı olup olmadığını belirleyen bir tür yazılım testi olarak tanımlanır. Bu, QA ekibinin daha ileri testlere devam edip edemeyeceğinin teyidi olarak hizmet eder. Duman testleri, her yapıda gerçekleştirilen minimum sayıda testtir. İşte duman testinin dahil olduğu döngü

Duman testi, yazılım yapısının QA ortamına dağıtıldığı ve uygulamanın kararlılığını sağlamak için doğrulandığı bir süreçtir. Aynı zamanda “Derleme Doğrulama Testi” veya “Güven Testi” olarak da adlandırılır.

Basit bir ifadeyle, önemli özelliklerin çalışıp çalışmadığını ve test aşamasında olan yapıda dikkat çekici hiçbir şeyin olmadığını doğruluyoruz.

Ana işlevselliğin mini ve hızlı bir regresyon testidir. Ürünün teste hazır olduğunu gösteren basit bir testtir. Bu, daha fazla test yapılmasının zaman ve kaynak israfına neden olacak şekilde yapının kusurlu olup olmadığının belirlenmesine yardımcı olur.

Duman testleri, yapıyı daha ileri resmi testlere uygun hale getirir. Duman testinin temel amacı, önemli sorunları erken tespit etmektir. Duman testleri, sistemin kararlılığını ve gereksinimlere uygunluğunu göstermek için tasarlanmıştır.

Bir yapı, bir veya daha fazla ürün işlevini uygulamak için gereken tüm veri dosyalarını, kitaplıkları, yeniden kullanılabilir modülleri ve tasarlanmış bileşenleri içerir.

Bu eğitimde şunları öğreneceksiniz:

Duman testini ne zaman yapıyoruz?

Duman Testi, yazılımın yeni işlevleri geliştirildiğinde ve QA/hazırlama ortamında dağıtılan mevcut yapıyla entegre edildiğinde yapılır. Tüm kritik işlevlerin doğru çalışıp çalışmadığını kontrol eder.

Bu test yönteminde, geliştirme ekibi yapıyı QA'da dağıtır. Test senaryolarının alt kümeleri alınır ve ardından test uzmanları yapı üzerinde test senaryolarını çalıştırır. QA ekibi uygulamayı kritik işlevlere göre test eder. Bu test senaryoları serisi, derlemedeki hataları ortaya çıkarmak için tasarlanmıştır. Bu testlerin geçilmesi durumunda QA ekibi Fonksiyonel Testlere devam eder.

Herhangi bir arıza, sistemin geliştirme ekibine geri gönderilmesi gerektiğini gösterir. Yapıda bir değişiklik olduğunda stabiliteyi sağlamak için Duman Testi yapıyoruz.

Örnek: -Oturum açma penceresine yeni kayıt butonu eklenir ve build yeni kod ile dağıtılır. Yeni bir yapı üzerinde duman testi yapıyoruz.

Duman Testini Kim Yapacak?

Yapıyı QA ortamına bıraktıktan sonra Duman Testi, QA mühendisleri/QA lideri tarafından gerçekleştirilir. Yeni bir yapı oluştuğunda, QA ekibi duman testini gerçekleştirmek için uygulamadaki ana işlevleri belirler. QA ekibi, test edilmekte olan uygulamadaki dikkat çekici unsurları kontrol eder.

Derlemeyi QA'ya yayınlamadan önce uygulamanın doğruluğunu sağlamak için kod üzerinde bir geliştirme ortamında yapılan testlere Sanity testi denir. Genellikle dar ve derin bir testtir. Geliştirilmekte olan uygulamanın temel işlevsel gereksinimlerini karşıladığını doğrulayan bir süreçtir.

Akıl sağlığı testi, geliştirme aşamasının tamamlandığını belirler ve daha sonraki test aşaması için yazılım ürününü geçip geçmeyeceğine karar verir.

Neden duman testi yapıyoruz?

Duman testi, sistemin başlangıç ​​aşamalarında doğruluğunu sağladığı için yazılım geliştirmede önemli bir rol oynar. Bu sayede test çabasından tasarruf edebiliriz. Sonuç olarak duman testleri sistemi iyi bir duruma getirir. Duman testini tamamladıktan sonra yalnızca işlevsel teste başlarız.

• Yapıdaki tüm gösteri durdurucuları duman testi yapılarak belirlenecektir.
• Duman testi, yapı QA'ya yayınlandıktan sonra yapılır. Duman testinin yardımıyla kusurların çoğu yazılım geliştirmenin ilk aşamalarında tespit edilir.
• Duman testiyle büyük kusurların tespitini ve düzeltilmesini kolaylaştırıyoruz.
• QA ekibi, duman testi yaparak, yeni kod nedeniyle ortaya çıkmış olabilecek uygulama işlevselliğindeki kusurları bulabilir.
• Duman testi en önemli ciddi kusurları bulur.

Örnek 1: Günlük penceresi: Gönder düğmesine tıklandığında geçerli kullanıcı adı ve şifreyle bir sonraki pencereye geçebilir.

Örnek 2: Kullanıcı web sayfasından çıkış yapamıyor.

Duman Testi Nasıl Yapılır?

Duman Testi genellikle manuel olarak yapılır, ancak aynı işlemin otomasyon yoluyla da gerçekleştirilmesi olasılığı vardır. Organizasyondan organizasyona farklılık gösterebilir.

Manuel Duman testi

Genel olarak duman testi manuel olarak yapılır. Yaklaşım bir kuruluştan diğerine farklılık gösterir. Kritik yollarda gezinmenin beklendiği gibi olmasını ve işlevselliği engellememesini sağlamak için duman testi gerçekleştirilir. Yapı QA'ya yayınlandıktan sonra yüksek öncelikli işlevsellik test senaryoları alınacak ve sistemdeki kritik kusurları bulmak için test edilecektir. Test başarılı olursa, işlevsel teste devam ederiz. Yapı reddedilirse ve düzeltme için geliştirme ekibine geri gönderilirse, sistemin doğruluğunu korumak için eski yapılarla entegre edilecek duman testine yeniden başlar. Duman testini gerçekleştirmeden önce QA ekibinin doğru yapı sürümlerini kontrol etmesi gerekir.

Bir hatayı/kusurun düzeltilmesi gibi gerekli değişiklikleri yaptıktan sonra, sorunun gerçekten çözüldüğünü doğrulamak için yazılım yeniden test edilmelidir. Uygulamanın işlevselliğini veya hata düzeltmesinin doğruluğunu doğrulamak için yazılımı yükledikten sonra yapılması gereken test türleri şunlardır:

- Duman testi(Duman Testi)

- Regresyon testi(Regresyon Testi)

- Yapıyı test etme(Derleme Doğrulama Testi)

- Sıhhi testler veya tutarlılık/işlevsellik kontrolü(Akıl Sağlığı Testi)

Konsept duman testi mühendislik ortamından geldi. Yeni ekipmanı (“donanım”) devreye alırken, kurulumdan duman çıkmaması durumunda testin başarılı olduğu kabul edildi. Yazılım testi alanında, tüm uygulama modüllerinin çalışabilirlik ve hızlı bir şekilde bulunan kritik ve engelleyici kusurların varlığı açısından yüzeysel olarak kontrol edilmesi amaçlanmaktadır. Duman testinin sonuçlarına göre yazılımın kurulu sürümünün test, işletim veya müşteriye teslim için kabul edilip edilmeyeceğine dair bir sonuca varılır. İşi kolaylaştırmak, zamandan ve insan gücünden tasarruf etmek amacıyla duman testi için test senaryosu otomasyonunun uygulanması önerilir.

Regresyon testiönceden var olan işlevselliğin amaçlandığı gibi ve daha önce çalıştığını doğrulamak için bir uygulamada veya ortamda yapılan değişiklikleri (bir kusurun düzeltilmesi, kodun birleştirilmesi, başka bir işletim sistemine, veritabanına, web sunucusuna veya uygulama sunucusuna geçiş) doğrulamayı amaçlayan bir test türüdür. (ayrıca bkz. Sıhhi test veya tutarlılık/işlevsellik testi). Regresyonlar şöyle olabilir işlevsel, yani ve işlevsel olmayan testler.

Kural olarak, regresyon testi için geliştirme ve testin ilk aşamalarında yazılan test senaryoları kullanılır. Bu, uygulamanın yeni sürümünde yapılan değişikliklerin mevcut işlevselliğe zarar vermemesini sağlar. Sonraki test sürecini hızlandırmak ve yazılım geliştirmenin erken aşamalarında hataları tespit etmek için regresyon testlerinin otomatikleştirilmesi önerilir.

"Regresyon testi" teriminin kendisi, kullanım bağlamına bağlı olarak farklı anlamlara sahip olabilir. Örneğin Sam Kaner şunları anlattı: 3 ana tip regresyon testi:

- Hata regresyonu- Düzeltilen hatanın gerçekte düzeltilmediğini kanıtlama girişimi.

- Eski hataların gerilemesi– kodda veya verilerde yakın zamanda yapılan bir değişikliğin eski hataların düzeltilmesini bozduğunu kanıtlama girişimi; eski hatalar yeniden ortaya çıkmaya başladı.

- Yan etki regresyonu– kodda veya verilerde yakın zamanda yapılan bir değişikliğin, geliştirilmekte olan uygulamanın diğer bölümlerini bozduğunu kanıtlama girişimi.

Akıl Sağlığı Testi – Bu, belirli bir özelliğin spesifikasyonda belirtildiği gibi performans gösterdiğini kanıtlamak için yeterli olan, oldukça odaklanmış bir testtir. Regresyon testinin bir alt kümesidir. Uygulamanın belirli bir bölümünün, üzerinde veya ortamda yapılan değişikliklerden sonra performansını belirlemek için kullanılır. Genellikle manuel olarak yapılır.

Sıhhi test ile duman testi arasındaki fark. Bazı kaynaklar yanlışlıkla hijyen ve duman testinin aynı şey olduğuna inanıyor. Bu tür testlerin farklı yönlerde “hareket vektörlerine” sahip olduğuna inanıyoruz. Duman testinin aksine Sanity testi, test edilen işleve derinlemesine yönelikken, duman testi mümkün olan en kısa sürede testlerle mümkün olduğunca fazla işlevselliği kapsayacak şekilde geniş kapsamlı olarak yönlendirilir.

Yapıyı test etme(Derleme Doğrulama Testi), teste başlamak için yayımlanan sürümün kalite kriterlerine uygunluğunu belirlemeyi amaçlayan testtir. Hedefleri açısından, daha ileri testler veya operasyonlar için yeni bir versiyonun kabul edilmesini amaçlayan Duman Testine benzemektedir. Yayınlanan sürümün kalite gereksinimlerine bağlı olarak daha derinlere nüfuz edebilir.

Kurulum Testi – Başarılı kurulum ve yapılandırmanın doğrulanmasının yanı sıra yazılımın güncellenmesi veya kaldırılması amaçlanır. Şu anda, yazılım yüklemenin en yaygın yolu kullanmaktır. montajcılar(kendileri de uygun test gerektiren özel programlar). Gerçek koşullarda kurulumcu olmayabilir. Bu durumda, gerekli tüm eylemleri ve kontrolleri adım adım açıklayan talimatlar veya benioku dosyaları biçimindeki belgeleri kullanarak yazılımı kendiniz yüklemeniz gerekecektir. Uygulamanın halihazırda çalışan bir ortamda konuşlandırıldığı dağıtılmış sistemlerde, basit bir talimat seti yeterli olmayabilir. Bunu yapmak için genellikle yalnızca uygulamayı yükleme adımlarını değil, aynı zamanda arıza durumunda önceki sürüme geri dönme adımlarını da içeren bir kurulum planı yazılır (Dağıtım Planı). Kurulum planının kendisi de fiili kullanıma alındığında sorunların önlenmesi için bir test prosedüründen geçmelidir. Bu, özellikle kurulumun her dakika kesintinin itibar kaybı ve büyük miktarda para anlamına geldiği sistemlerde gerçekleştirilmesi durumunda geçerlidir; örneğin: bankalar, finans şirketleri ve hatta banner ağları. Bu nedenle kurulum testi, yazılım kalitesinin sağlanmasında en önemli görevlerden biri olarak adlandırılabilir.

Kurulum testi veya Kurulum Testi olarak adlandırılabilecek şey, planların yazılması, adım adım kurulum testi ve kurulumun geri alınmasını içeren bu kapsamlı yaklaşımdır.

Çeviri, yazarın kendi deneyimlerinden edindiği düşünceler ve eklemelerle seyreltilmiştir.

Bütün bunlar neyle ilgili?

Bu makalede, bu test türleri arasındaki farkı netleştirip açıklamak ve bunu anlamaya, bir test türünün nerede bitip diğerinin nerede başladığını (koşullu da olsa) çizmeye çalışmak istiyorum.

Test etmeye yeni başlayanlar (ve hatta deneyimli testçiler) için bu kavramları birbirinden ayırmak zor olabilir. Ve gerçekten, temizlik testinin nerede başladığını ve duman testinin nerede bittiğini nasıl anlarsınız? Sistemin veya bileşenlerinin işlevselliğinin bir kısmının testini "duman" testi olarak adlandırmak için ne kadar sınırlamamız gerekiyor? Bir sitedeki kullanıcı giriş formuna kullanıcı adı/şifre girmek bir duman testi midir, yoksa bunun bir site sayfasında görünmesi zaten başarılı bir test midir?

Kesin olarak konuşursak, farkın tam olarak ne olduğunu söyleyemeseniz bile yine de test edebileceksiniz. Şu anda ne tür testler yaptığınızı ayırt etmeyi düşünmenize bile gerek yok. Ama yine de profesyonel anlamda kendinizin üstüne çıkabilmek için neyi, neden yaptığınızı, ne kadar doğru yaptığınızı bilmeniz gerekiyor.

Eğitim programı

• Duman testleri: test için bir projenin (sistemin) yeni bir yapısını (versiyonunu) aldığımızda, nispeten kararsız olduğu düşünüldüğünde gerçekleştirilir. Kritik AUT (Test Edilen Uygulama) fonksiyonlarının beklendiği gibi çalıştığından emin olmamız gerekiyor. Bu tür testlerin amacı, ciddi sorunları mümkün olduğu kadar erken tespit etmek ve uzun ve karmaşık testlere dalmamak için bu yapıyı testin erken bir aşamasında reddetmek (revizyona geri dönmek), böylece zaman kaybını önlemektir. açıkça kusurlu yazılımda.
• Sıhhi testler: Performansı ayrıntılı olarak belirlemek için nispeten kararlı bir yazılım yapısı elde ettiğimizde her zaman kullanılır. Başka bir deyişle, sistem işlevselliğinin önemli bölümlerinin düşük düzeyde gerektiği gibi çalıştığının doğrulanmasıdır.

• Tekrar test et: özelliğin/işlevselliğin zaten kusurları varsa ve bu kusurlar yakın zamanda giderildiyse gerçekleştirilir
• Regresyon testleri: aslında zamandan aslan payını alan şey ve test otomasyonunun neden var olduğu. AUT'nin regresyon testi, yeni (eklenen) uygulama işlevlerinin / sabit kusurların, daha önce çalışan (ve test edilen) mevcut, mevcut işlevselliği etkilemediğinden emin olmak gerektiğinde gerçekleştirilir.

Ama esasen?

Örnek: Kullanıcı arayüzü ve RESTful API'si olan bir web servisimiz var. Testçiler olarak şunu biliyoruz:

• Basitlik açısından, aynı IP üzerinde bulunan durumumuzda 10 giriş noktasına sahip olması
• Hepsinin giriş için bir GET isteğini kabul ettiğini ve bazı verileri json formatında döndürdüğünü biliyoruz.

• Bu giriş noktalarından birine basit bir GET isteği yürüterek ve json formatında bir yanıt alarak, duman testinin geçtiğine zaten ikna olmuş durumdayız.
  Bu giriş noktalarından biri veritabanından veri döndürüyorsa ve ilki dönmüyorsa, uygulamanın çalıştığından emin olmak için ek olarak başka bir sorgu çalıştırmanız gerekir.
  veritabanına gelen istekleri doğru şekilde işler. Bu da “duman” testini tamamlıyor.

  Yani, isteği tamamladık - hizmetten bir yanıt geldi ve "duman çıkarmadı", yani 4xx veya 5xx hatasını ve json yerine belirsiz bir şeyi döndürmedi. Bu noktada “duman” testinin geçtiğini söyleyebiliriz. Kullanıcı arayüzünün aynı şekilde çalıştığını kontrol etmek için sayfayı tarayıcıda bir kez açmanız yeterlidir.

• Bu durumda sıhhi test, API'deki 10 giriş noktasının tamamına bir talep yürütülmesinden, alınan json'un beklenen json ile kontrol edilmesinden ve ayrıca içinde gerekli verilerin bulunup bulunmadığından oluşacaktır.
• Regresyon testleri, aynı yığında birlikte çalışan duman + akıl sağlığı + kullanıcı arayüzünden oluşacaktır. Hedef: 11. giriş noktasının eklenmesinin (örneğin, şifre kurtarma) bozulmadığını kontrol edin.
• Bu örnekteki yeniden test, örneğin bir sonraki yapıdaki bozuk bir API giriş noktasının amaçlandığı gibi çalışıp çalışmadığının tek tek kontrol edilmesidir.

Özetleyelim

GÜNCELLEME:
Çoğunlukla "tutarlılık testi" veya "akıl sağlığı testi", "sıhhi test" olarak anılır. Bunun, ses olarak "sıhhi" bir şeye benzeyen İngilizce sanity kelimesinin fonetik özelliklerinden kaynaklandığını düşünüyorum. Google Çeviri netlik sağlar. Her iki seçenek de internette mevcuttur. Bu makaleyle ilgili olarak lütfen "sıhhi" testi "tutarlılık testi" olarak düşünün.

İpucu için teşekkürler