Yeni Başlayanlar İçin Eksiksiz İşlevsel Olmayan Test Kılavuzu

complete non functional testing guide

İşlevsel Olmayan Test için Eksiksiz Kılavuz: Amacı, Türleri, Aracı, Örneklerle Test Örnekleri

İşlevsel Olmayan Test Nedir?

Uygulamanın Performans, Kullanılabilirlik vb. Gibi işlevsel olmayan gereksinimlerini doğrulamak için işlevsel olmayan test yapılır.

Sistemin davranışının ihtiyaca göre olup olmadığını doğrular. Kapsanmayan tüm yönleri kapsar fonksiyonel test . Günlük testlerimizde, fonksiyonel testlere ve fonksiyonel gereksinimlere büyük önem verilmektedir.

Müşteriler ayrıca, bir uygulamanın işlevselliği ile doğrudan ilişkili olan işlevsel gereksinimleri karşılamakla da ilgilenirler. Ancak gerçek aşamada, yani işlevsel olarak test edildiğinde, yazılım pazara girer ve gerçek son kullanıcılar tarafından kullanılır ve performansla ilgili bazı sorunlarla yüzleşme şansı vardır.

Bu sorunlar sistemin işlevselliği ile ilgili olmamakla birlikte kullanıcı deneyimini olumsuz yönde etkileyebilir. Bu nedenle, olumsuz müşteri deneyiminden kaçınmak için yazılımın veya uygulamanın İşlevsel Olmayan gereksinimler için de test edilmesi önemlidir.

Test, genel olarak iki türe ayrılır:

• Fonksiyonel test
• İşlevsel Olmayan Test

Ne öğreneceksin:

• Önem
• Amaç
• Misal
• Avantajları
• İşlevsel Olmayan Gereksinimler Nasıl Yakalanır?
  • # 1) Kullanıcı / Teknik Hikayeler
  • # 2) Kabul Kriterleri
  • # 3) Eserlerde
• İşlevsel ve İşlevsel Olmayan Gereksinimlerdeki Fark
• Bu Kara Kutu mu yoksa Beyaz Kutu Testi mi?
• İşlevsel Olmayan Test Durumları Kontrol Listesi
  • Performans Testi için Kontrol Listesi
  • Güvenlik testi için kontrol listesi
  • Dokümantasyon Testi için Kontrol Listesi
• Yaklaşım Belgesi
  • Test Kapsamı
  • Test Metrikleri
  • Test Araçları
  • Önemli Tarihler ve Teslim Edilecekler
• İşlevsel Olmayan Test Türleri
• İşlevsel Olmayan Test Araçları
  • # 1) Kullanılabilirlik Testi Test durumları
  • # 2) Performans Testi Test durumları
  • # 3) Güvenlik Testi test durumları
• Sonuç
• Önerilen Kaynaklar

Önem

Sistemin işlevselliğini etkilemediği için bu teste gereken özen gösterilmemiştir.

İşlevsel Olmayan gereksinimlere de önceki test döngülerinde yeterince ilgi gösterilmemiştir. Ancak bu artık değişti. İşlevsel olmayan testler, bugünlerde tüm uygulama performansı ve güvenlik sorunlarını göz önünde bulundurdukları için artık çok önemlidir.

Yüksek kullanıcı trafiği altındaki uygulamanın performansı söz konusu olduğunda bu testin uygulamalar üzerinde daha büyük bir etkisi vardır. Bu test, uygulamanızın kararlı olmasını ve aşırı koşullar altında yükü kaldırabilmesini sağlar.

Adından da anlaşılacağı gibi, bu test, uygulamanın işlevsel olmayan yönüne odaklanmaktadır. Peki fonksiyonel olmayan yönler nelerdir? Ya da uygulamanın işlevselliği ile ilgili olmayan özellikler nelerdir demeliyim?

İşte bunların cevapları:

• Uygulama normal şartlar altında nasıl işliyor?
• Aynı anda çok fazla kullanıcı oturum açtığında uygulama nasıl davranır?
• Uygulama stresi kaldırabilir mi?
• Uygulama ne kadar güvenli?
• Uygulama herhangi bir felaketten kurtulabilir mi?
• Uygulama farklı bir ortamda veya işletim sisteminde aynı şekilde davranabilir mi?
• Uygulamayı farklı bir sisteme taşımak ne kadar kolay?
• Uygulama ile birlikte verilen belgeler / kullanım kılavuzu anlaşılması kolay mı?

Liste devam ediyor. Ancak buradaki nokta şu - bu özellikler uygulamanın kalitesine katkıda bulunmadı mı? Cevap Evet. Bu özellikler eşit derecede önemlidir.

Bir uygulamanın tüm kullanıcı gereksinimlerini mükemmel bir şekilde karşıladığını, ancak bazı yetkisiz kullanıcıların uygulamada kullanıcı tarafından girilen verilere kolayca gidip bunları kırdığını veya herhangi bir dosyanın 5BB'den fazlası yüklendiğinde uygulama ölür. Peki uygulamanın kaliteli olduğunu söyleyebilir misiniz? Açıkçası doğru değil !!

Amaç

Bu tür testlerin tek amacı, uygulamanın işlevsel olmayan yönlerinin test edilmesini ve uygulamanın aynı bağlamda iyi çalışmasını sağlamaktır.

Amaç, iş beklentisini karşılayan bir uygulama sağlamaya yardımcı olan uygulamanın tüm özelliklerinin test edilmesini kapsamaktır.

Misal

Bu, önemli bir test türüdür.

İşlevsel test, uygulamanın işlevselliğini test eder ve beklendiği gibi çalışmasını sağlar, ancak işlevsel olmayan testler, uygulamanın iş beklentilerini karşılayacak kadar iyi çalışmasını sağlar.

Önemini anlamak için basit bir Örnek alalım:

Bir uygulama geliştirilir ve işlevsellik açısından tamamen test edilir, ancak işlevsel olmayan testler aynı şekilde gerçekleştirilmez.

Bu arada, uygulama devreye girdiğinde, uygulama üzerindeki yükün artması gibi kritik veya büyük sorunlara neden olabilir, çok yavaşlar ve açılması çok zaman alır.

Tepki süresi artabilir veya yük bir miktar arttığında uygulama çökebilir. Bu, bir uygulamanın işlevsel olmayan yönlerini test etmenin ne kadar önemli olduğunu gösterir.

Avantajları

İşlevsel olmayan bir testin avantajlarından bazıları aşağıda verilmiştir:

• Fonksiyonel testler kapsamına girmeyen testleri kapsar.
• Uygulamanın verimli çalışmasını ve yeterince güvenilir olmasını sağlar.
• Uygulamanın güvenliğini sağlar.

İşlevsel Olmayan Gereksinimler Nasıl Yakalanır?

Test gerçekleştirirken, odak noktası esas olarak ürünün işlevselliğini test eden fonksiyonel testlerdir. Ancak fonksiyonel olmayan testler, fonksiyonel testler kadar önemlidir ve gereklilikleri, ürünün başlangıcından itibaren dikkate alınmalıdır.

İşlevsel Olmayan testler gerçekleştirmek için İşlevsel Olmayan gereksinimler kullanılır. Bu gereksinimler, uygulamadan veya test edilen yazılımdan beklenen performans çıktısını içerir. Bu, temel olarak, yazılımın belirli bir sistemi çalıştırmak için harcadığı zamanı içerir.

İşlevsel olmayan gereksinimler, yazılımı aynı anda çok sayıda insanın kullandığı davranışları da yakalar. Çoğu zaman, sunucuların ağır yük nedeniyle meşgul veya kullanılamaz olduğu deneyimlenir (yani, aynı anda daha fazla insan kullanıyor). Online tren bileti rezervasyonu en iyisi olabilir misal böyle bir durumun.

Bu nedenle, İşlevsel Olmayan gereksinimin doğru şekilde belgelenmesi ve testin doğru yapılması, potansiyel müşteriler tarafından kullanılabilirlik açısından yüksek memnuniyet sağlayacaktır.

Bu testin, sistemin işlevselliği üzerinde doğrudan bir ticari etkisi olmamasına rağmen, kullanıcı deneyimini ve kullanım kolaylığını daha yüksek bir ölçüde artırabilir ve bu da, yazılımın kalitesi üzerinde daha büyük bir etkiye sahip olacaktır.

Misal:

Aynı Facebook giriş sayfası örneğini düşünün. Bu durumda, İşlevsel Olmayan testin kapsamı, sistemin geçerli kimlik bilgilerini girdikten sonra Facebook'ta oturum açmak için gereken süreyi not etmektir.

Ayrıca, kullanıcıların aynı anda ne zaman (100 diyelim) giriş yaptıkları, kullanıcının Facebook'ta oturum açmasının ne kadar zaman alacağı gibi test edilebilir.

Bu, sistemin yük ve trafiğin üstesinden gelebilmesini ve dolayısıyla da iyi bir kullanıcı deneyimine sahip olmasını sağlar.

Çevik olarak, işlevsel olmayan gereksinim girdiler kullanılarak yakalanmalıdır.

İşlevsel olmayan bir gereksinim şu şekilde ele alınmalıdır:

• Kullanıcı / Teknik Hikayeler
• Kabul kriterlerinde
• Yapıtta

9

# 1) Kullanıcı / Teknik Hikayeler

İşlevsel olmayan bir gereksinim, kullanılarak yakalanabilir Kullanıcı hikayeleri veya teknik hikayeler. İşlevsel olmayan gereksinimleri bir kullanıcı öyküsü olarak yakalamak, herhangi bir gereksinimi yakalamakla aynıdır. Kullanıcı ve teknik hikaye arasındaki tek fark, kullanıcı hikayesinin tartışma gerektirmesi ve görünürlüğe sahip olmasıdır.

# 2) Kabul Kriterleri

Kabul kriterleri Ürünü müşteri tarafından kabul etmek için tanımlanan nokta yani ürünün belirlenen noktalara kabul edilmesini sağlamak için geçiş durumunda olmalıdır.

İşlevsel olmayan bir gereksinim, kabul kriterlerine dahil edilmelidir, ancak bazen işlevsel olmayan gereksinimleri her öyküde, yani her yinelemede test etmek mümkün olmayabilir. Bu nedenle, gereksinimler yalnızca ilgili yinelemeyle eklenmeli veya test edilmelidir.

# 3) Eserlerde

İşlevsel olmayan gereksinimler için ayrı bir yapı hazırlanmalıdır, bu da neyin test edilmesi gerektiği ve yinelemelerde nasıl yapılabileceği konusunda daha iyi bir fikre sahip olmaya yardımcı olacaktır.

İşlevsel ve İşlevsel Olmayan Gereksinimlerdeki Fark

İşlevsel ve işlevsel olmayan gereksinimler arasında birkaç fark vardır ve bunlardan birkaçı aşağıda belirtilmiştir:

Daha fazla okuma => İşlevsel ve İşlevsel Olmayan Test arasındaki farklar

Bu Kara Kutu mu yoksa Beyaz Kutu Testi mi?

İşlevsel olmayan test, bir kara kutu testi tekniği.

Bu teknik, yalnızca işlevleri test etmekle sınırlı değildir, aynı zamanda işlevsel olmayan gereksinimleri ve ayrıca Performans, kullanılabilirlik vb. Test etmek için de kullanılabilir. Kara kutu test tekniği, dahili sistem hakkında herhangi bir bilgi gerektirmez, yani gerektirmez. test edene kod bilgisi.

İşlevsel Olmayan Test Durumları Kontrol Listesi

Test edilmeden önemli bir yönün kalmamasını sağlamak için bir kontrol listesi kullanılır.

Kontrol listesi genellikle dokümantasyon için zaman olmadığında ve ürünün test edilmesi gerektiğinde veya bir zaman kısıtlaması olduğunda, tüm önemli hususların kapsanmasını sağlamak için bir kontrol listesi kullanılabilir.

Bir bakalımmisalPerformans, Güvenlik ve Dokümantasyon testi kontrol listesi.

Performans Testi için Kontrol Listesi

• Tepki süresi Uygulamanın doğrulanması gerekir, yani uygulamanın yüklenmesi ne kadar sürer, uygulamaya verilen herhangi bir girdi çıktıyı ne kadar sürede sağlar, tarayıcının yenilenmesi vb.
• Çıktı Bir yük testi sırasında tamamlanan işlemlerin sayısı doğrulanmalıdır.
• Çevre kurulum canlı ortamla aynı olmalıdır, aksi takdirde sonuçlar aynı olmaz.
• İşlem süresi - Excel'in ithalatı ve ihracatı gibi süreç faaliyetleri, uygulamadaki tüm hesaplamalar test edilmelidir.
• Birlikte çalışabilirlik doğrulanmalıdır, yani bir yazılım diğer yazılımlar veya sistemlerle birlikte çalışabilmelidir.
• ETL zaman doğrulanmalıdır, yani verilerin bir veritabanından diğerine çıkarılması, dönüştürülmesi ve yüklenmesi sırasında geçen süre.
• Artan Yük uygulama doğrulanmalıdır.

Güvenlik testi için kontrol listesi

• Doğrulama: Yalnızca gerçek bir kullanıcı Giriş yapabilmelidir.
• Yetkili: Kullanıcı, yalnızca yetkili olduğu veya kullanıcıya erişim izni verilen modüllerde oturum açabilmelidir.
• Parola: Parola gereksinimi doğrulanmalıdır, yani parola gereksinimin nasıl tanımladığına göre olmalıdır, yani uzunluk, özel karakterler, sayılar vb.
• Zaman aşımı: Uygulama etkin değilse, belirli bir süre içinde zaman aşımına uğramalıdır.
• Veri yedekleme: Veri yedeklemesi belirli bir zamanda alınmalı ve güvenli bir yere kopyalanmalıdır.
• İç bağlantılar doğrudan tarayıcıya yerleştirilmişse web uygulamasına erişilememelidir.
• Tüm iletişim şifrelenmelidir.

Dokümantasyon Testi için Kontrol Listesi

• Kullanıcı ve Sistem belgeleri.
• Eğitim amaçlı belgeler.

Yaklaşım Belgesi

Genel Test stratejisini iyileştirerek Performans Testi aşaması için özel bir yaklaşım dokümanı geliştirin. Bu Test yaklaşımı, tüm Performans Testi görevlerinin planlanması ve yürütülmesinde rehberlik eder.

mp4 dönüştürücü için en iyi ücretsiz mov

• Test Kapsamı
• Test Metrikleri
• Test Araçları
• Önemli Tarihler ve Teslim Edilecekler

Test Kapsamı

Kullanıcı performansı, iş süreçleri, sistem kararlılığı, kaynak tüketimi vb. Gibi farklı bakış açılarından Performans Testi gerçekleştirin. Uygulanacak Performans Testi Türleri, makalenin yukarıdaki bölümünde (Yük testi, Stres testi vb.) Tartışılmıştır.

Test Metrikleri

Test yaklaşımı, Test sırasında ölçmek ve raporlamak için aşağıdaki gibi metrikleri iyileştirir:

• Yanıt süresi (çevrimiçi)
• Toplu iş penceresi (toplu iş)
• Çıktı ( Örneğin birim zaman başına işlem sayısı)
• Kullanım ( Örneğin , kullanılan kaynakların yüzdesi)

Test Araçları

Çoğunlukla Performans Testi, uygun araçların kullanılmasını gerektirir:

• Yük oluşturma araçları
• Performans izleme araçları
• Performans analizi araçları
• Uygulama profili oluşturma araçları
• Taban astarı araçları.

Önemli Tarihler ve Teslim Edilecekler

Performans Testi Yaklaşım Belgesi aşağıdakileri açıklamalıdır:

• Her Performans Testinin gerçekleştirildiği tarih ve saat.
• Her Performans Testi uygulamasına dahil edilecek test türleri ve işlevsellik karışımı.
• Performans Testi tamamlanma tarihleri.

İşlevsel Olmayan Test Türleri

Aşağıdaki resimde, İşlevsel Olmayan test türleri gösterilmektedir:

Performans testi:

Sistemin genel performansını değerlendirir .

Anahtar unsurlar aşağıdaki gibidir:

• Sistemin beklenen yanıt süresini karşıladığını doğrular.
• Uygulamanın önemli unsurlarının istenen yanıt süresini karşıladığını değerlendirir.
• Ayrıca, entegrasyon testi ve sistem testinin bir parçası olarak da gerçekleştirilebilir.

Yük Testi:

Sistemin performansının normal ve beklenen koşullar altında beklendiği gibi olup olmadığını değerlendirir.

Anahtar noktalar:

• Eşzamanlı kullanıcılar uygulamaya eriştiğinde ve beklenen yanıt süresini aldığında sistemin beklendiği gibi çalıştığını doğrular.
• Bu test, yanıt süresi ve verimi elde etmek için birden çok kullanıcıyla tekrarlanır.
• Test sırasında veritabanı gerçekçi olmalıdır.
• Test, gerçek ortamı uyaran özel bir sunucuda yapılmalıdır.

Stres testi:

Kaynaklar yetersiz olduğunda sistemin performansının beklendiği gibi olup olmadığını değerlendirir.

Anahtar noktalar:

• Normal koşullar altında bulunamayan kusurları ortaya çıkaran istemcilerde / sunucularda düşük bellek veya düşük disk alanı üzerinde test edin.
• Birden çok kullanıcı, aynı veriler üzerinde aynı işlemleri gerçekleştirir.
• Farklı iş yüklerine sahip sunuculara birden çok istemci bağlanır.
• Sunucuları maksimum stres altında tutmak için Düşünme Süresini 'Sıfıra' düşürün.

Düşünme Zamanı: Tıpkı kullanıcı ve şifrenizin yazılması arasındaki zaman aralığı gibi.

Hacim Testi:

Büyük miktarda veri söz konusu olduğunda yazılımın davranışını değerlendirir.

Anahtar noktalar:

• Yazılım büyük miktarda veriye maruz kaldığında, yazılımın başarısız olduğu sınırı kontrol eder.
• Maksimum veritabanı boyutu oluşturulur ve birden çok istemci veritabanını sorgular veya daha büyük bir rapor oluşturur.
• Misal - Uygulama, bir rapor oluşturmak için veritabanını işliyorsa, hacim testi, büyük bir sonuç kümesi kullanmak ve raporun doğru yazdırılıp yazdırılmadığını kontrol etmek olacaktır.

Kullanılabilirlik testi:

Sistemi insan kullanımı için değerlendirir veya kullanıma uygun olup olmadığını kontrol eder.

Anahtar noktalar:

• Çıktı doğru ve anlamlı mı ve işletme açısından beklenenle aynı mı?
• Hatalar doğru teşhis edildi mi?
• GUI, standartla doğru ve tutarlı mı?
• Uygulamanın kullanımı kolay mı?

Kullanıcı Arayüzü Testi:

GUI'yi değerlendirir.

Anahtar noktalar:

• GUI, kullanımı kolaylaştırmak için yardım ve araç ipuçları sağlamalıdır.
• Görünüşüyle ​​tutarlı mı?
• Veriler bir sayfadan diğerine doğru şekilde aktarılıyor mu?
• GUI, kullanıcıyı rahatsız etmemeli veya anlaşılması zor olmamalıdır.

Uyumluluk Testi:

Uygulamanın minimum ve maksimum konfigürasyonla diğer donanım / yazılımlarla uyumlu olduğunu değerlendirir.

Anahtar noktalar:

• Her donanımı minimum ve maksimum yapılandırmayla test edin.
• Farklı tarayıcılarla test edin.
  Test senaryoları, fonksiyonel test sırasında gerçekleştirilenlerle aynıdır.
• Donanım ve yazılım sayısının çok fazla olması durumunda, maksimum kapsama sahip olmak için test senaryolarına ulaşmak için OATS tekniklerini kullanabiliriz.

Kurtarma Testi:

Herhangi bir arıza durumunda uygulamanın sorunsuz bir şekilde sona erdiğini ve verilerin herhangi bir donanım ve yazılım arızasından uygun şekilde kurtarıldığını değerlendirir.

Testler aşağıdaki hususlarla sınırlı değildir:

• CURD aktivitelerini yaparken müşteriye güç kesintisi.
• Geçersiz veritabanı işaretçileri ve anahtarları.
• Veritabanı işlemi iptal edildi veya zamanından önce sonlandırıldı.
• Veritabanı işaretçileri, alanları ve anahtarları manuel olarak ve doğrudan veritabanı içinde bozulur.
• İletişimin fiziksel olarak bağlantısını kesin, gücü kapatın, yönlendiricileri ve ağ sunucularını kapatın.

Kararsızlık Testi:

Yazılımın doğru şekilde kurulup kaldırılıp kaldırılmadığını değerlendirir ve onaylar.

qa mühendis mülakat soruları ve cevapları

Anahtar noktalar:

• Sistem bileşenlerinin belirlenen donanıma doğru şekilde kurulduğunu doğrular.
• Yeni makinede gezinmenin mevcut kurulumu ve eski sürümleri güncellediğini doğrular.
• Yetersiz disk alanı olduğunda kabul edilemez davranış olmadığını doğrular.

Dokümantasyon Testi:

Belgeleri ve diğer kullanım kılavuzlarını değerlendirir.

Anahtar noktalar şunları içerir:

• Üründe belirtilen belgelerin mevcut olduğunu doğrular.
• Tüm kullanıcı kılavuzlarını, kurulum talimatlarını, beni oku dosyalarını, sürüm notlarını ve çevrimiçi yardımı doğrular.

Yük Devretme Testi:

Yük devretme testi, bir sistem arızası durumunda sistemin sunucular gibi ekstra kaynakları idare etmeye yetecek kadar yetenekli olduğunu doğrulamak için yapılır.

Böyle bir durumu önlemek için yedekleme testi büyük rol oynar. Bir yedekleme sistemi oluşturmak, sürecin tamamı ile ilgilidir. Yedekleme mevcutsa, sistemi geri almaya yardımcı olur.

Güvenlik Testi:

Güvenlik testi uygulamanın herhangi bir veri kaybına veya tehdide yol açabilecek herhangi bir boşluk bulunmadığından emin olmak için yapılır. İşlevsel olmayan testlerin önemli yönlerinden biridir ve doğru şekilde yapılmazsa güvenlik tehditlerine yol açabilir.

Kimlik doğrulama, yetkilendirme, bütünlük ve kullanılabilirliğin test edilmesini içerir.

Ölçeklenebilirlik Testi:

Ölçeklenebilirlik testi, uygulamanın artan trafiği, işlem sayısını, veri hacmini vb. İdare etmeye yetecek kadar yetenekli olup olmadığını doğrulamak için yapılır. Veri hacmi veya veri boyutunda değişiklik yapıldığında sistem beklendiği gibi çalışmalıdır.

Uyum testi:

Tanımlanan standartların takip edilip edilmediğini doğrulamak için uygunluk testi yapılır. Aynısını doğrulamak için denetimler yapılır.

İçin Misal , Test senaryoları / test planları oluşturma sürecini doğrulamak ve bunları standart isimle yapılıp yapılmadığı paylaşılan yere yerleştirmek için denetimler yapılır. QC'de, test senaryolarını adlandırırken standart test senaryosu adı takip ediliyor veya edilmiyor. Dokümantasyon tamamlandı ve onaylandı veya onaylanmadı.

Bunlar, denetim sırasında ele alınan birkaç işarettir.

Dayanıklılık Testi:

Dayanıklılık Testi bir yük uzun bir süre arttırıldığında sistemin davranışını doğrulamak için yapılır.

Ayrıca Soak testi ve Kapasite testi olarak da adlandırılır. Sistemde herhangi bir bellek sızıntısı olup olmadığını doğrulamaya yardımcı olur. Dayanıklılık testi, yük testinin bir alt kümesidir.

Yerelleştirme Testi:

Yerelleştirme testi uygulamayı farklı dillerde, yani farklı yerel ayarlarda doğrulamak için yapılır. Başvuru, belirli bir kültür veya yerel ayar için doğrulanmalıdır. Ana odak, uygulamanın GUI'sini, içeriğini test etmektir.

Uluslararasılaşma Testi:

Uluslararasılaştırma testi i18n testi olarak da bilinir.

I18n, I - sekiz harfi - N'yi temsil eder. Uygulamanın tüm dil ayarlarında beklendiği gibi çalışıp çalışmadığını doğrulamak için yapılır. Herhangi bir işlevin veya uygulamanın kendisinin bozulmadığını, yani uygulamanın tüm uluslararası ayarları kaldırabilecek kadar yetenekli olması gerektiğini doğrular.

Ayrıca, uygulamanın herhangi bir sorun olmadan kurulduğunu doğrular.

Güvenilirlik Testi:

Güvenilirlik testi, uygulamanın güvenilir olup olmadığını ve tanımlanan ortamda belirli bir süre test edilip edilmediğini doğrulamak için yapılır. Bir uygulama her seferinde beklendiği gibi aynı çıktıyı vermelidir, ancak o zaman güvenilir olarak kabul edilebilir.

Taşınabilirlik Testi:

Taşınabilirlik testi, bir yazılımın / uygulamanın farklı bir sisteme veya farklı bir platforma kurulup kurulmaması durumunda beklendiği gibi çalışıp çalışmayacağını, yani ortamdaki bir değişiklik nedeniyle hiçbir işlevselliğin etkilenmemesi gerektiğini doğrulamak için yapılır.

Test ederken, uygulamanın doğru davranışının ve beklenen işlevselliğinin sağlam olduğundan emin olmak için değişikliği sabit disk alanı, İşlemci gibi donanım yapılandırmasında ve ayrıca farklı işletim sistemlerinde test etmek gerekir.

Temel Test:

Temel test aynı zamanda karşılaştırma testi test edilecek her yeni uygulama için bir temel oluşturduğu için.

Örneğin: İlk yinelemede, bir uygulamanın yanıt süresi 3 saniyeydi. Şimdi, bu bir sonraki yineleme için bir ölçüt olarak belirlendi ve sonraki yinelemede yanıt süresi 2 saniyeye değişiyor. Temelde gelecekteki referanslar için temel olarak kullanılan bir doğrulama belgesidir.

Verimlilik Testi:

Uygulamanın verimli çalışıp çalışmadığını ve gerekli kaynak sayısını, gerekli araçları, karmaşıklığı, müşteri gereksinimini, gerekli ortamı, zamanı, ne tür bir proje olduğunu vb. Doğrulamak için verimlilik testi yapılır.

Bunlar, dikkate alınan tüm parametreler beklendiği gibi çalışırsa bir uygulamanın ne kadar verimli çalışacağını tanımlamaya yardımcı olacak bazı işaretçilerdir.

Felaket Kurtarma Testi:

Bu test, herhangi bir kritik arıza meydana gelirse bir uygulamanın veya sistemin kurtarılmasının başarı oranını ve sistemin verileri ve uygulamayı geri yükleyebildiğini veya sistemin daha önceki çalışma biçimine dönmek için kolayca başa çıkıp çıkamayacağını doğrulamak için yapılır. operasyonel cephe.

Sürdürülebilirlik Testi:

Uygulama / Ürün yayınlandıktan sonra, canlı ortamda bir sorunun ortaya çıkma olasılığı vardır veya müşteri zaten yayında olan uygulama için bir geliştirme isteyebilir.

Bu durumda, yukarıda belirtilen senaryoları test etmek için bakım test ekibi mevcuttur. Uygulama yayınlandıktan sonra, bakım testi ekibinin çalıştığı bir bakıma ihtiyacı vardır.

İşlevsel Olmayan Test Araçları

Piyasada Performans (Yük ve Stres) testi için çeşitli araçlar mevcuttur.

Birkaç tanesi aşağıda listelenmiştir:

• JMeter
• Loadster
• Loadrunner
• Yük fırtınası
• Neoload
• Tahmin
• Yükleme Tamamlandı
• Web sunucusu Stres Aracı
• WebLoad Professional
• Loadtracer
• vPerformer

İşlevsel Olmayan Testler Daima Dokümantasyon ve Test Vakaları Olmadan Yapılır mı? Neden?

'Her zaman işlevsel test senaryolarının nasıl yazılacağı öğretiliyor. Neden? 'İşlevsel olmayan testler' dokümantasyon olmadan mı gerçekleştiriliyor (başka bir deyişle, anlık olarak) yoksa bu, anlaşılması çok daha zor olan ayrı bir süreç mi? Bir uygulamada gerçekleşen farklı test türleri için test senaryoları nasıl yazılır? '

Bu, son zamanlarda bana sorulan en özgün, özgün ve kullanıma hazır sorulardan biridir. Cevabı bulalım.

Nasıl oluyor da işlevsel olmayan test senaryoları yazma konusunda hiçbir zaman görüp pratik yapamıyoruz?

Şimdi bildiklerimizle ve her zaman olduğu gibi pratik bir senaryo ile başlayalım.

Misal: Bir İnternet Şubesi uygulamasında havale yapmak için yapılması gerekenler aşağıda belirtilmiştir. Bunu referans testimiz olarak kullanalım.

1. Siteye giriş yapın.
2. Banka hesabını seçin.
3. Alacaklıyı seçin (bu alacaklı aynı bankaya veya farklı bir bankaya ait olabilir - bu, bu adımı uygulamak için veri seçiminize bağlıdır. Her durumda, birini seçin. Ayrıca, alacaklının zaten eklendiğini varsayacağız.) .
4. Transfer edilecek miktarı girin (pozitif değer, limit dahilinde, doğru format, vb.).
5. Transfer'i tıklayın ve onay alınıp alınmadığını, hesap bakiyesinin güncellendiğini ve hepsini kontrol edin.

Bu işlevsel test durumu, doğru mu?

Aynı uygulamada, aynı transferler sayfasında, diyelim ki performans yapıyoruz Performans, Güvenlik ve Kullanılabilirlik Testi . Bunlar işlevsel olmayan tipler, doğru mu?

Test durumlarını nasıl yazacağız?

# 1) Kullanılabilirlik Testi Test durumları

Kullanılabilirlik testi, kullanıcı deneyimiyle ilgilenen bir yazılım testi türüdür. Bunlar cevaplamaya çalıştığımız sorulardan bazıları.

• Uygulamanın kullanımı ne kadar kolay?
• Sistemi kullanma deneyimi ne kadar tatmin edici?
• Hemen o kadar tanıdık gelmediyse, öğrenmek ne kadar kolay?

Bununla ilgili daha fazla bilgi burada: Kullanılabilirlik Testi Kılavuzu

Bir kullanıcı, kullanılabilirlik testi bağlamında yukarıdaki soruların yanıtlarını nasıl belirler?

Kullanıcı, işlevsel test durumunda olduğu gibi yapmak için tam olarak aynı adımları gerçekleştirecektir. Haklı mıyım

# 2) Performans Testi Test durumları

Performans testinin çeşitli varyasyonları vardır, ancak özünde, çeşitli yük noktalarında sistem, kaynak kullanımı, yanıt süresi, ağ tüketimi vb. Hakkında istatistikler almak için kullanılır.

Göz atın Performans Testi Eğitimleri hakkında daha fazla bilgi edinmek için.

Şimdi, aktarım işleminin performansını test edecek olsaydım, 10, 20, 30, 100… 1000… vb. Kullanıcıların, neyi hedeflemek ve hakkında veri toplamak istediğime bağlı olarak eşzamanlı veya artımlı olarak aktarım işlemini gerçekleştirmesini isterdim.

Performans testi devam ederken aktarımı kullanmak için her kullanıcı hangi adımları gerçekleştirir?

Fonksiyonel test ile aynı adımlar, doğru mu?

# 3) Güvenlik Testi test durumları

Güvenlik Testi, yazılım sistemlerini hack'lenmeye karşı korumaya yardımcı olan bir QA dalıdır. Güvenlik açıklarını (yazılım sistemindeki olası sorunlu alanları) tanımlar, penetrasyon veya beyaz şapka testi tekniği yoluyla bunları kullanır ve döngü delikleri bulunduğunda üzerinde çalışılır.

Transferlerin bilgisayar korsanlarına karşı korumalı olup olmadığını ve hedeflenen alıcılara doğru bir şekilde yönlendirilip yönlendirilmediğini ve tüm süreçte siyah nokta olmadığını ne zaman kontrol etmek istiyorum? Transferi, güvenlik sızıntılarının izlenmesi süreci paralel olarak devam ederken yapardım.

Bu nedenle, aslında, işlevsel bir test durumu durumunda normalde yapacağım adımların aynısını gerçekleştiriyorum.

Sanırım, tüm durumlarda adımların aynı olduğunu belirlemeye yetecek kadar var. Sürecin arkasındaki yöntem ve niyet farklı olan şeydir.

Karşılaştırmalı bir göz atalım:

İlginç olan şey şudur: ne tür bir test yapmak istediğimiz önemli değil, tüm adımlar aynı .

Gerçek fark şudur:

1. Bu adımları kim gerçekleştiriyor?
2. Niyetim nedir, başka bir deyişle bu testle neyi başarmaya çalışıyorum?
3. Kullanılan araçlar ve teknikler.

Sorumuza geri dönecek olursak, neden işlevsel olmayan test senaryoları yazmayı tüm ayrıntılı adımlarla birlikte yazmayı asla öğrenemiyoruz?

Çünkü ,özünde, belirli bir işlevdeki test türlerinde bir varyasyon için test adımlarının tümü aynıdır, işlevseldir veya değildir. Fark yaratan niyet ve belki de yöntemdir.

Sonuç

İşlevsel olmayan testleri gerçekleştirmeden önce, uygun testi sağlamak için test stratejisini doğru şekilde planlamak önemlidir. Piyasada bu tür testleri gerçekleştirmek için Load Runner, RPT vb. Gibi farklı araçlar vardır.

Bu test, bir uygulamanın başarısında ve iyi bir müşteri ilişkisi kurmasında önemli bir rol oynar ve bu nedenle ihmal edilmemelidir. Bu, Yazılım testinin önemli kısımlarından biridir ve bu olmadan testin tamamlanmış olduğu düşünülemez.

İşlevsel olmayan test ayrıntılarını test planına dahil edebilir veya bunun için ayrı bir strateji oluşturabiliriz. Her iki durumda da amaç, yazılımın işlevsel olmayan yönlerinin uygun şekilde kapsanmasıdır.

Bu konunun derinliklerine inme sürecinin, hepinize sunulduğu kadar sizin için de eğlenceli olduğunu umuyoruz. Bu konudaki görüşlerinizi ve görüşlerinizi duymak isteriz.

Ekiplerinizde fonksiyonel olmayan testleri nasıl ele alıyorsunuz? Ve her zaman olduğu gibi, burada olup bitenlere katılıyor veya katılmıyorsanız veya ekleyecek bir şeyiniz varsa bize bildirin.

Önerilen Kaynaklar

• Fonksiyonel Test ve Fonksiyonel Olmayan Test
• Alfa Testi ve Beta Testi (Tam Kılavuz)
• Web Uygulaması Güvenliği Test Kılavuzu
• Türleri ve Örneği ile Eksiksiz Fonksiyonel Test Kılavuzu
• Derleme Doğrulama Testi (BVT Testi) Tam Kılavuzu
• En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
• Web Uygulaması Sızma Testi İçin Yeni Başlayanlar Kılavuzu
• Yeni Başlayanlar İçin Yük Testi Tam Kılavuzu