static testing dynamic testing difference between these two important testing techniques
Test Doğrulama ve onaylama . Hepimiz, testi tamamlamak için 2 V gerektiğini biliyoruz.
Bugünün makalesinde, biraz ışık tutacağız. Statik test . Doğrulama da denir. Her şeyi öğreneceğiz ve buna özel önem vereceğiz çünkü Dinamik test genellikle azami dikkat çeker ve onu detaylandıran sayısız makale içerir.
Bununla birlikte, statik test üzerine hiçbir tartışma, muadili dinamik testin ne anlama geldiğine dair bir açıklama olmadan tamamlanmayacaktır. Dinamik test, doğrulamadır, diğer 'V' dir.
Dinamik test, gerçek sistemle çalıştığınız zamandır (bunu temsil eden bir yapı veya model değil) sistem), bir girdi sağlamak, çıktı almak ve çıktıyı beklenen davranışla karşılaştırmak. Hataları bulmak amacıyla sistemle uygulamalı olarak çalışmaktır.
Bu süreçte, testlerle ilgili aşağıdaki iki yaygın yanlış anlamanın nasıl doğru olmadığını anlayacağız:
- Test, sonunda gelen bir faaliyettir
- Sadece testçiler tarafından yapılır ve geri kalanlarının yapacak hiçbir şeyi yoktur.
Hızlı bir referansla başlayalım. v modeli :
- Üzerinde Sol taraftaki V modelinde, QA ekibi tarafından gerçekleştirilmeyen faaliyetlerimiz var.
- Üzerinde sağ taraf , bazıları Dev ekibi tarafından, bazıları testçiler tarafından ve bazıları da kullanıcılar tarafından halledilen bazılarına sahibiz.
İle başlayalım - Gereksinimlerin Toplanması . İş Analisti ve diğer üst düzey yönetim tarafından gerçekleştirilir - bu aşamanın çıktı belgesi BRD İş gereksinimi belgesidir.
Bir sonraki aşama Sistem tasarımı . Sistem tasarımı, iş gereksinimlerinin FRD'de (İşlevsel gereksinimler belgesi) İşlevsel gereksinimlere çevrildiği bir aşamadır.
Çeviri yapılırken, Geliştirme ekibi (bu adımda ana aktör olan) BRD belgesini adım adım, sayfa sayfa ve satır satır gözden geçirecek. Birincil hedef, çeviri uğruna iş gereksinimlerini tüketmek olsa da, BRD belgesi sırayla inceleniyor.
Bir örnek: Bunun, güvenlik açısından büyük bir bankacılık sitesi için BRD olduğunu varsayalım. BRD'de, çevrimiçi bankacılık sitesinde bir hesap oluşturan çeşitli kullanıcılar için şifre kurallarından bahseden bir bölüm vardır. Kurallardan biri: Bir kullanıcı, diğer hesaplar için kullandığı bir şifreyi kullanamaz.
Bu mümkün değil. Çünkü bir site, kullanıcının sadece oturum açma kimlik bilgilerini nasıl ayarlaması gerektiğini önerebilir, ancak hiçbir şekilde bu kısıtlama getirilebilir. Bu nedenle, bu gereklilik uygulanabilir değildir - başka bir deyişle, yazılım aracılığıyla gerçekleştirilemez.
kabarcık sıralama algoritması c ++
Şimdi bu örneğe dayanarak şu noktaları ele alalım:
- Bu gereksinimin geliştirilemeyeceği ve bu nedenle test edilemeyeceği (başka bir deyişle, uygulanabilir olmadığı) nasıl belirlenir? Bankanın sitesine sahip miyiz ve daha sonra kullanıcı adı ve şifreyi ayarlayıp bunun mümkün olmadığını anlıyor muyuz? Hayır, bunu sadece BRD incelememize ve tabii ki bazı sağduyuya dayandırıyoruz.
- Bu gereksinimi test ediyor muyuz? Elbette, ancak tamamen teorik, kavramsal duyuya dayanıyor, ancak gerçek AUT'ye (Test Altındaki Uygulama) değil.
- Bu testin fiziksel şekli nedir? - BRD'nin basit bir okuması veya resmi bir incelemesi ya da iş gereksinimlerinin daha resmi bir fizibilite analizi.
Yanlış kanılarımıza geri dönersek:
- BRD'nin bu incelemesini kim yapıyor? - Çoğunlukla geliştirme ekibi ve ürünü oluşturmaktan sorumlu diğer teknik ekipler. Test kullanıcıları değil.
- Ürün oluşturmanın sonunda bu inceleme devam ediyor mu? Hayır, proje geliştirmenin ilk aşamasında. Dolayısıyla, sadece son değil.
Statik Test Teknikleri:
Özetlemek gerekirse, statik test, aşağıdaki yöntemleri izleyen yazılım testinin doğrulama kısmıdır:
- Belge incelemeleri
- İzlenecek yollar
- Muayene
- Yazılımın olması gerekip gerekmediğini belirlemek için fizibilite analizi veya diğer herhangi bir analiz şekli
- Kod incelemesi
CSTE CBOK'tan alıntı yapmak için, 'Doğrulama,' Doğru sistemi kurduk mu? 'Sorusunu yanıtlıyor. doğrulamalar ise 'Sistemi doğru oluşturduk mu?'
Aşağıdakiler, V modelinin sol tarafında gerçekleşen tüm statik test faaliyetleridir.
| SDLC aşaması | Çıktı | Doğrulamalar | Aktörler |
|---|---|---|---|
| İş gereksinimi toplama | BRD (İşletme Gereksinimi belgesi) | Kapsam belgesi (varsa) | |
| Sistem gereksinimi tasarımı | FRD (İşlevsel gereksinim belgesi) | BRD'yi inceler / doğrular | Dev, Teknik ekipler |
| Teknik gereksinim tasarımı | TDD (Teknik Tasarım Dokümanı) | FRD'yi inceler / doğrular | Dev, Teknik ekipler |
| Tasarım kodu) | Kod | TDD'yi inceler / doğrular. Eksiksizlik, format vb. İçin geliştirici ekip tarafından kod incelemesi | Dev, Teknik ekipler |
Not: Bu bilgiler, herhangi bir geliştirme metodolojisini izleyen projeler için tahmin edilebilir, çünkü adımlar aşağı yukarı benzer olacaktır.
V modelinin sağ tarafında doğrulama var.
Dinamik Test Teknikleri:
yazılım testinde test senaryosu biçimi
- Birim Testi
- Entegrasyon Testi
- Sistem Testi
Birim, entegrasyon, sistem ve UAT aşamalarının tamamı, geliştirmenin çeşitli aşamalarında AUT üzerinde gerçekleştirilecek testler oluşturmakla ilgilidir. Testler, farklı türdeki gereksinimleri doğrulamayı hedeflese de, hepsi aynı testlerdir.
Öyleyse, bir AUT üzerinde yürütülmesi gereken bir testin olduğu ve testin sonucunu (başarılı olsun ya da olmasın) belirlemek için çıktısının gerekli olduğu herhangi bir test türü - bu doğrulamadır.
Şimdi, V modelinin sağ tarafında (RHS) hiçbir doğrulama olmadığını genellemek doğru olur mu? Cevap hayır.
RHS'nin her aşamasında oluşturulan tüm testler, test oluşturma / sonlandırma aşamasında birkaç kez gözden geçirilir. Ayrıntılı test belgeleri inceleme süreci şu adrestedir: https://www.softwaretestinghelp.com/test-documentation-reviews/
RHS hakkında:
- Testler ve kod, geliştiriciler tarafından Birim / Entegrasyon testi aşamalarında gözden geçirilir.
- Sistem Testleri, dokümantasyonları sırasında bir meslektaş incelemesinden geçer ve tamamlandıktan sonra, geliştirici ekibi ve İş analisti tarafından bir incelemeye tabi tutulur.
- UAT testleri, UAT başlamadan önce QA ekibi ve kullanıcılar tarafından bir incelemeye tabi tutulur.
Sonuç
Sonuç olarak, statik test, İş gereksinim incelemesi, İşlevsel gereksinim incelemesi, tasarım incelemeleri, kod gözden geçirmeleri ve test belgeleri incelemesi şeklini alan önemli bir test tekniğidir. Sürekli bir faaliyettir ve sadece testçiler tarafından yapılmaz.
Doğrulama, dinamik test bölümü daha pratiktir ve ürünün bir yapıtında veya bir temsilinde değil, ürünün kendisinde gerçekleşir. Çok resmi bir test senaryosu / durumu tanımlama, kapsam konuları, yürütme ve hata raporlama, dinamik test yöntemlerini işaretler.
Yazar hakkında: Bu makale STH ekip üyesi Swati S. tarafından yazılmıştır.
Lütfen statik ve dinamik test konusu hakkındaki yorumlarınızı, sorularınızı ve deneyimlerinizi paylaşın.
Önerilen Kaynaklar
- Masaüstü, İstemci Sunucu Testi ve Web Testi arasındaki fark
- Çevik Tahmin Teknikleri: Çevik Bir Projede Doğru Bir Tahmin
- Kara Kutu Testi: Örnekler ve Tekniklerle Derinlemesine Bir Eğitim
- Uygunluk Testi (Uygunluk testi) nedir?
- SIT ile UAT Testi Arasındaki Fark Nedir?
- Alfa Testi ve Beta Testi (Tam Kılavuz)
- Kara Kutu Testi ile Beyaz Kutu Testi Arasındaki Temel Farklılıklar
- Birim Testi, Entegrasyon Testi ve İşlevsel Test Arasındaki Farklar