structural testing tutorial what is structural testing
Bu kapsamlı Yapısal Test Eğitimi, Yapısal Testin ne olduğunu, türlerini, Kontrol Akışı Testi ve Kontrol Akışı Grafiğinin ne olduğunu, Kapsama Düzeylerini vb. Açıklar:
En pahalı yazılım hatalarının bazılarına yönelik hızlı bir Google araması, zihnimi sersemletti - 500 milyar dolar. Evet, bir hata bu kadar maliyetli olabilir. Bir yazılım hatası nedeniyle ulaşım ve sağlık sektörlerinde kaybedilen hayatlarla ilgili herhangi bir şeyi okumak da korkunç olabilir.
Koddaki hatalar, çok miktarda para ve can kaybını içerdiği durumlarda her zaman aşırı olmamakla birlikte, burada iletmeye çalıştığımız tek anahtar çıkarım, testlerin gözden kaçamayacağıdır.
SDLC genelinde test sık sık yapıldığında, ürünün gönderilmesinden sonra düzeltmek için çok daha fazla zamana ihtiyaç duyan hataları yakalamamıza olanak tanır.
Önemli olan, seçtiğimiz yazılım test türleridir. İşlevsel, yapısal ve değişikliğe dayalı testler dahil olmak üzere bunlardan birkaçı vardır.
Bu eğitimde ayrıca Yapısal Test Türleri de açıklanmaktadır. Mutasyon Testi, Dilim Tabanlı Test, Veri Akışı Testinin nasıl yapılacağını örnekler ve açıklamalarla ayrıntılı olarak öğrenin.
Ne öğreneceksin:
- Yazılım Testi Neden Önemli?
- Yapısal Test Nedir
- Yapısal Test Türleri
- Yapısal Testin Avantajları ve Dezavantajları
- En İyi Yapısal Test Uygulamaları
- Sonuç
Yazılım Testi Neden Önemli?
Para biriktirmeye ve yukarıda bahsedilen durumlar gibi felaketlerden kaçınmaya ek olarak, test etmenin önemini haklı çıkarmak için başka birkaç neden daha vardır.
Bazı nedenler aşağıda listelenmiştir:
# 1) Öngörülen gereksinimlerin karşılandığından emin olmak için bir proje oluşturmaya başlamadan önce. Paydaşlar (örneğin, geliştiriciler ve müşteriler) bir proje oluşturmak için gerekli olan çözüm / ürün / yazılımın tüm yönleri üzerinde anlaşmalıdır.
Test, yazılım gereksinimlerinin karşılanıp karşılanmadığının doğrulanmasını içerir. Çözümün oluşturulmasına dahil olan geliştirici veya şirket, eclat koduyla çalıştırılan bu kadar yüksek kaliteli bir çözüm tasarlama konusunda iyi bir itibar kazanır.
# 2) Kod işlevinin amaçlandığı gibi çalıştığını doğrular. Test aynı zamanda yazılımın işlevselliğinin doğrulanmasını da içerir ve herhangi bir arıza durumunda, SDLC'nin (Yazılım Geliştirme Yaşam Döngüsü) erken aşamalarında düzeltilmesi gerekir.
# 3) Performansı kontrol eder: Örneğin, kodu çalıştırırken geçen toplam süreyi belirlemek için. Birkaç kullanırsak Döngüler için kodumuzda, istenen çıktıyı elde etmek uzun zaman alır ve hatta bazen zaman aşımına uğrayabilir.
# 4) Daha iyi bir kullanıcı deneyimi elde etmeye yardımcı olur. Kullanıcılar, arızalı, hatalı veya 'çok yavaş' yazılımları kullanmaktan hoşlanmayacaklar. Kullanıcılar muhtemelen sabırsızlanacak ve yazılımı kullanmayı bırakacaktır. Testler, kullanıcıların ürünlerimizi kolayca kullanabilmelerini sağlamak için bize daha iyi bir şans verir.
# 5) Ölçeklenebilirliği kontrol eder. Bir geliştirici, ölçeklenebilir bir yazılım geliştirmeyi hedeflemelidir.
# 6) Koddaki güvenlik açıklarını kontrol eder. Testler bize güvenlik açıklarına dikkat etme fırsatı verir, Örneğin, ödün verebilecek kod PII GDPR için yüksek öncelikli olan (Kişisel Olarak Tanımlanabilir Bilgiler).
Bu makalede, bir tür teste odaklanacağız, yani Yapısal Test . Adından da anlaşılacağı gibi, kodun yapısı ile ilgisi vardır. Bu, testin kod performansı, işlevsellik ve güvenlik gibi yönleri belirlemeye yardımcı olduğu daha önce bahsettiğimizden farklıdır.
Yapısal Test ve Diğer Test Türleri
Birçok yazılım testi türü vardır. Ancak DUR (International Software Testing Qualifications Board), 4 ana yazılım test türünü tanımlar:
- İşlevsel
- İşlevsiz
- Yapısal
- Değişime dayalı
Farklılıklar şu şekilde açıklanabilir:
Fonksiyonel test: Bu, yazılımın işlevselliğinin öngörülen gereksinimlere göre doğrulanmasını içerir. Test verileri girdi olarak kullanılır. Verilen çıktının beklendiği gibi olup olmadığını da kontrol ediyoruz.
İşlevsel olmayan test : Bu, yazılımın ne kadar iyi çalıştığını analiz etmek için bir test sürecini içerir, Örneğin, aynı anda idare edebileceği kullanıcı sayısı.
Yapısal testler: Bu test türü, kodun yapısına dayanır. Örneğin, bir kodun bir dizideki çift sayıların ortalamasını hesaplaması amaçlanıyorsa, yapı temelli test, son çıktının doğru bir sayısal değer olup olmadığından ziyade, 'ortalamanın hesaplanmasına yol açan adımlar' ile ilgilenecektir.
Çift sayıları tek sayılardan ayıran kodu tanımlayıp tanımlamadığımızı kontrol etmemiz gerektiğini varsayalım. Burada bir koşullu ifadeye sahip olabiliriz, örneğin, bir dizi elemanı ikiye bölünebilirse, kalansızsa, eğer (dizi (i)% 2 === 0) daha sonra sayı çift sayı olarak söylenebilir.
Yapısal testler, kodu en iyi anladıkları şekliyle yazan kişiler tarafından gerçekleştirilir.
Değişime dayalı test : Bu, kodda değişiklik yapmanın etkilerinin test edilmesini ve ardından yapılan değişikliklerin uygulandığından emin olmayı içerir. Ayrıca, kodda yapılan değişikliklerin onu bozmamasını da sağlar.
Yapısal Test Ne Değildir
Yapı bazlı testin kodun yapısıyla ilgili olduğunu daha önce bahsetmiştik. Unutmayın, burada gerçek kodla ilgileniyoruz. Gereksinimleri kontrol etmiyoruz ve hatta girdileri beklenen çıktılarla karşılaştırmıyoruz. Bu noktada işlevsellik, kullanıcı deneyimi ve hatta performansla ilgilenmiyoruz.
Yapısal Test Nedir
Yapı tabanlı test, bu nedenle, kodun yapısını ve amaçlanan akışları test eden bir yazılım testi türü olarak tanımlanabilir. Örneğin, koşullu ifadelerin doğru uygulanması ve koddaki her ifadenin doğru şekilde yürütülüp yürütülmediği gibi yönler için gerçek kodu doğrulama. Yapı temelli test olarak da bilinir.
Bu tür testleri gerçekleştirmek için kodu iyice anlamamız gerekir. Bu nedenle, bu test genellikle kodu en iyi anladıkları şekilde yazan geliştiriciler tarafından yapılır.
Yapısal Test Nasıl Yapılır
Kodun farklı yönlerini test etmek için önce kontrol akışlarını anlamamız gerekir.
Kontrol Akışı Testi
Bu, kodun kontrol akışlarından (ifadelerin, işlevlerin ve kodun farklı yönlerinin uygulandığı sıra) testler türetmektir.
Kontrol Akışı Test Süreci:
Kontrol Akış Grafiği
Kontrol akışı süreci, yürütme sırasında izlenebilecek yolları tanımlamamıza yardımcı olan kodun farklı bölümlerinin görsel bir temsilini oluşturarak başlar.
Bu görsel temsiller Kontrol Akışı Grafikleri (CFG'ler) olarak bilinir ve düğümler, kenarlar, yollar, kavşaklar ve karar noktaları gibi çeşitli bileşenlere sahiptir. Grafik, kaynak koddan grafiği çıkarmak için yazılımın kullanıldığı manuel veya otomatik olarak oluşturulabilir.
Aşağıdaki bileşenlere bakalım:
nasıl ürün testçisi olurum
# 1) İşlem bloğu
Bu bölüm, sırayla çalıştırılan bir kod bölümünü temsil etmek için kullanılır. Bu, her seferinde aynı şekilde yürütüldüğü ve yapılması gereken hiçbir karar veya 'dallanma' olmadığı anlamına gelir. Tek giriş ve çıkış yolu olan düğümlerden oluşur.
İşlem bloğu örneği:
(resim kaynak )
İşlem bloğu, kontrol akışının önemli bir parçası değildir ve sonuç olarak yalnızca bir kez test edilmesi gerekir.
# 2) Karar noktaları
Bunlar, kodun kontrol akışındaki bazı temel bileşenlerdir. Bu düğümler içinde kararlar alınır. Bu genellikle karşılaştırma yoluyla yapılır ve karara bağlı olarak kontrol akışı değişir. CFG'nin bu kısmı, en az 2 çıkışlı bir düğümden oluşur.
Burada verilen karar, if-else ifadeleri (iki olası çıktıya sahip) ve durum ifadeleri (ikiden fazla çıktıya sahip olabilir) gibi koşullu ifadeler olabilir.
(resim kaynak )
Yukarıdaki diyagramda, 'evet' veya 'hayır' seçeneklerinin izlediği bir karar noktası (koşullu 'yaş = 18' den) vardır.
# 3) Bağlantı noktaları
Yukarıdaki diyagramdan, karar noktalarının birleştiği noktalara göre bağlantı noktalarını kolayca belirleyebiliriz. Bağlantı noktalarının birçok giriş yolu olabilir, ancak yalnızca bir çıkış yolu olabilir.
Kontrol akış grafikleri en iyi uygulamaları:
Kontrol akış grafikleri oluştururken dikkat edilmesi gereken birkaç nokta vardır:
- CFG'yi basit tutmak için mümkün olduğunca çok çalışın. Bunu, 'daha az önemli' olarak kabul edilebilecek parçaları birleştirerek yapabiliriz, Örneğin, işlem blokları.
- Karar noktalarında yalnızca bir kararın alınmasını sağlayın. Daha karmaşık CFG'lerde, karar verildikten sonra gelen 'sonuçlar' vardır. Yukarıdaki örneğimizde, bir kişi 18 yaşında veya daha büyükse, uygun olduğunu ve bir bilet için ödeme yapması gerektiğini de ekleyebiliriz. Değilse, giriş ücretsizdir. 'Diğer' kararının birkaç düğümü 'atlaması' gerekir ve tüm bu adımların CFG'mizde gösterilmesi gerekir.
CFG'mizi tanımladıktan sonra, şimdi kontrol akışı test sürecindeki bir sonraki adıma, yani kodu ne ölçüde test edeceğimizi tanımlama zamanı.
Ne kadar test edileceğini tanımlama:
Kaynak kodun ne kadarı test edilmelidir? Olası her yolu test etmeli miyiz? Testlerimizdeki tüm yolları kaplamaya çalışmak neredeyse imkansızdır. Ne kadar test yapabileceğimizi belirlemek için bir orta yol bulmalıyız.
Kodumuzun% 50'sini test etmeyi hedeflediğimizi söylersek, bu, tüm çalıştırılabilir kod ifadelerini tanımlayacağımız ve bunların en az yarısını test etmeyi hedefleyeceğimiz anlamına gelebilir. Bununla birlikte, burada ortaya çıkan soru, 'O zaman tüm olası çalıştırılabilir yolları tanımlamamız gerekiyor mu?'
Bu yine pratik olarak imkansız olabilir. Daha iyi bir yaklaşım, kodun her bölümünde belirleyebileceğimiz yolların% 50'sini test etmeyi amaçlamak olabilir.
Bildirim, şube ve yol kapsamı gibi farklı teminat seviyeleri vardır. Bunlara daha sonra kısaca bakacağız.
Test senaryoları oluşturma:
Bir sonraki adım, kullanacağımız test senaryolarını oluşturmaktır. Yapı bazlı testlerdeki test senaryoları aşağıdaki faktörlere dayanmaktadır:
- Yürütülebilir ifadeler.
- Alınması gereken 'kararlar'.
- İzlenebilecek olası yollar.
- Karşılanması gereken koşullar (bunlar çoklu veya mantıksal olabilir).
Yukarıdaki faktörler, oluşturmamız gereken test senaryolarının türleri hakkında bize bir fikir verir. Ayrıca yapısal bir test oluşturma aracı da kullanabiliriz. Kodumuz C programlama dilindeyse, test kodu oluşturmak için PathCrawler'ı kullanabiliriz. Kullanabileceğimiz diğer bir araç fMBT'dir.
Test senaryolarının yürütülmesi:
Burada testleri yapacağız. Kodun onu nasıl çalıştırdığını kontrol etmek için girdi veya veri girebilir ve ardından beklenen sonuçları alıp almadığımızı doğrulayabiliriz. Örneğin, Döngüden sonra elde ettiğimiz sonuçların gözlemlenmesi veya karar noktalarının doğru kararları verip vermediğini kontrol etmek için işlev çağrısına bir dizi girin.
Sonuçları analiz etmek:
Bu bölümde tek yaptığımız, yürütmeden sonra doğru sonuçları alıp almadığımızı kontrol etmektir. Örneğin, tüm değerlerin 18'in üzerinde olduğu bir dizi girersek, o zaman 'uygun' ile sonuçlanan tüm karar noktalarına sahip olmamız gerekir.
Kontrol Akışı Varsayımları
Kontrol akış testinin gerçekleştirilmesi için yapılan birkaç varsayım olduğuna dikkat etmek önemlidir. Bunlar şunları içerir:
- Mevcut tek hatalar, kontrol akışını etkileyebilecek olanlardır.
- Tüm değişkenler, işlevler ve öğeler doğru bir şekilde tanımlanmıştır.
Kontrol Akışlarında Kapsama Düzeyleri
Daha önce bahsettiğimiz gibi, kontrol akış testinde farklı kapsam seviyeleri vardır.
Onlara kısaca bakalım.
# 1) Bildirim Kapsamı
Yapısal testlerde, yürütülebilir kod ifadeleri, testleri tasarlama yöntemlerine karar verirken hayati bir rol oynar.
en iyi youtube'dan mp3'e dönüştürücü nedir?
% 100 kapsama elde etmeyi hedefliyoruz, bu da her yürütülebilir ifadenin en az bir kez test edildiği anlamına gelir. Kapsam ne kadar yüksekse, hataları ve hataları gözden kaçırma olasılığı o kadar azdır.
Burada test senaryolarının kullanılması gerekmektedir. İhtiyaçlar için gittiğimiz veriler, bir kod bloğundaki her çalıştırılabilir ifadenin en az bir kez yürütülmesini sağlamaktır.
# 2) Şube Kapsamı
Bu kapsam seviyesi, CFG dallarındaki (kararların alındığı) noktaların test edilmesini içerir. Sonuçlar boolean. Bir switch ifadesi kullanılsa ve birden fazla sonuç olsa bile, özünde, her durum bloğu bir çift değerin karşılaştırmasıdır.
Ekstre teminatında olduğu gibi% 100 şube kapsamını hedeflemeliyiz. Bunu başarmak için, her bir sonucu her karar düzeyinde en az bir kez test etmemiz gerekir. Boole sonuçlarıyla uğraştığımız için, kodun her bölümü için en az 2 test çalıştırmayı hedeflemeliyiz.
# 3) Yol Kapsamı
Bu kapsam seviyesi, karar ve beyan kapsamına kıyasla daha kapsamlıdır. Buradaki amaç, tüm olası yolları 'keşfetmek' ve en az bir kez test etmektir. Bu son derece zaman alıcı olabilir. Bununla birlikte, kodumuzdaki hataları veya hataları veya hatta tanımlamamız gereken yönleri keşfetmeye yardımcı olabilir, Örneğin, kullanıcı girişi.
Yapısal Test Türleri
(resim kaynak )
Mutasyon Testi
Mutasyon testi, bir yazılım uygulamasının çeşitli varyasyonlarının test veri setine göre test edildiği hataya dayalı bir test tekniğidir.
>> Daha ayrıntılı bir bakış için bu eğiticiye bakın Mutasyon testi.
Dilim Tabanlı Test
Dilim Tabanlı Test (SBT), temel alan bir yazılım test tekniği olarak tanımlanabilir. dilimler - programın belirli ilgi noktalarında bazı değerleri etkileyen programın çalıştırılabilir bölümleri veya ifade grupları, Örneğin, değişkenlerin tanımlandığı kısımlar veya bir grup ifadenin çıktısı.
Dilimleme Nasıl Yapılır
SBT'de dilimleme örneği: Çift ve tek sayıları yazdırmak için kod (Python)
num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Bir dilime bakmanın iki yolu vardır: İlgili değişkenin yolunu veya kodun çıktıyı etkileyen bölümünü izleyerek.
Örneğimizde tek sayı çıktısına bakarsak, kodun bizi bu çıktıya götüren kısmını izleyebiliriz.
Mark Weiser (SBT'yi tanıtan) tarafından verilen dilimleme kriterlerinde, bu formül kullanılarak bir dilim tanımlanır: S (v, n) , nerede, v söz konusu değişkeni ifade eder ( Örneğin, bir değişkenin tanımlandığı) ve n ilgi beyanıdır ( Örneğin, çıktının verildiği yer) ve S dilim için duruyor.
Yukarıdaki örnekte, dilimi elde etmek için, 10. satırdaki çıktımızdan başlıyoruz, bu da bizim n . Değişkenimiz nerede .
Yani dilimleme kriterlerimiz:
S(v,n) = S(var,10)
Endişemiz, bizi çıktıya götüren ifadelerdir.
Bunlar:
10,9,8,4,3,1
Yani, bu koddaki dilimimiz:
num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Dilim Tabanlı Test Türleri
İki tür SBT vardır: Statik ve Dinamik
# 1) Dinamik Dilim Tabanlı Test
Tek sayıların yazdırılmasını etkileyen ifadelere baktığımız yukarıda açıklanan SBT örneği dinamik SBT'dir. Endişemiz çok özel. Yalnızca belirli çıktıyı doğrudan etkileyen şeylere odaklanmalıyız.
Kodu çalıştırır ve olması gerektiği gibi çalıştığından emin olmak için test verilerini kullanırız. Aralığı (1,50) aralığına yükseltebiliriz, Örneğin, hala tek sayılar üretip üretmediğini görmek için. Dinamik SBT, doğrulama testi olarak da bilinir.
# 2) StatikDilim Tabanlı Test
Dinamik SBT'nin aksine, statik testin odak noktası belirli bir değişkendir. Yukarıdaki örnekte çıktımızı şöyle düşünürsek nerede , onu etkileyen dilimi şu şekilde izleyebiliriz: 10,9,8,7,6,5,4,3,2,1
Temelde kod bloğunun tamamıdır! Burada kodun sözdizimi ve gereksinimler açısından doğru olduğunu onaylıyoruz ve onu çalıştırmıyoruz. Statik SBT, doğrulama testi olarak da bilinir.
Dinamik SBT'nin statik karşılığı ile karşılaştırıldığında 'daha küçük' olduğuna dikkat etmek önemlidir. Ayrıca daha spesifiktir.
Dilim Tabanlı Test En İyi Uygulamaları / Yönergeleri
Dilimleme kriterleri şu şekilde belirlenmelidir:
- Değerlerin tanımlandığı veya atandığı ve değerin yeniden atandığı ifadeler.
- Program dışından değerlerin alındığı ifadeler, Örneğin, kullanıcı girişi yoluyla.
- Çıktı / geri dönüş çıktılarını yazdıran ifadeler.
- Programın son ifadesi, Örneğin, değerleri tanımlayabilen veya argümanlara değerler sağlayabilen bir işlev çağrısı
Dilim tabanlı testin avantajları şunları içerir:
- SBT'de yalnızca belirli ilgi alanlarıyla çalıştığımızdan, test takımlarını etkili bir şekilde oluşturmayı kolaylaştırır.
- Yol, kod içindeki bağımlılıklar tarafından tanımlanır, bu kullanmaktan daha iyidir yol kapsamı.
- SBT ile, kaynak koddaki hataları bulmak daha kolaydır.
Dilim tabanlı testin dezavantajları şunları içerir:
- Büyük bir kod tabanını test ederken dinamik test kullanırsak, çok sayıda hesaplama kaynağına ihtiyacımız olacaktır.
- Statik test kullanırsak, hataları gözden kaçırabiliriz.
Veri Akışı Testi
Veri akışı testi, veri değerlerine ve bunların bir programdaki kullanımına dayanan bir yazılım test tekniği olarak tanımlanabilir. Veri değerlerinin doğru şekilde kullanıldığını ve doğru sonuçları ürettiğini doğrular. Veri akışı testi, belirli bir yürütme yolundaki veri değerleri arasındaki bağımlılıkları izlemeye yardımcı olur.
Veri Akışı Anormallikleri
Veri akışı anormallikleri, bir yazılım programındaki basit hatalardır. Sırasıyla tip 1, 2 ve 3 olarak sınıflandırılırlar.
Aşağıda bunları inceleyelim:
Tür 1: Bir değişken tanımlanır ve ona iki kez bir değer atanır.
Örnek kod: Python
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var)
Lst_1 tanımlanır ve ona iki farklı değer atanır. İlk değer basitçe göz ardı edilir. Tip 1 anormallikleri programın başarısız olmasına neden olmaz.
Tip 2: Bir değişkenin değeri, tanımlanmadan önce kullanılır veya referans alınır.
Örnek kod: Python
for var in lst_1: print(var)
Yukarıdaki döngü, üzerinde yinelenecek değerlere sahip değildir. Tip 2 anormallikleri programın başarısız olmasına neden olur.
Tip 3: A veri değeri oluşturulur, ancak asla kullanılmaz.
Örnek kod: Python
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var)
Değişken lst_2 başvurulmamış. Tip 3 anormallikleri program hatasına neden olmayabilir.
Veri Akışı Test Süreci
Veri değerleri arasındaki bağımlılıkları tanımlamak için, bir programda izlenebilecek farklı yolları tanımlamamız gerekir. Bunu etkili bir şekilde yapmak için, şu adıyla bilinen başka bir yapısal test türünden ödünç almamız gerekir: kontrol akışı testi .
Aşama 1) Bir kontrol akış grafiği çizin
Programımızda izleyebileceğimiz yolların grafiksel bir temsili olan bir kontrol akış grafiği çizmemiz gerekiyor.
Örnek kod: Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)
Yukarıdaki kod örneğinde, bir üye bir ziyaretçiyi davet ederse indirim almalıdır.
Kontrol Akış Grafiği (CFG):
Adım 2) Değişkenlerin ve veri değerlerinin tanımını ve kullanımını keşfedin.
Bir programdaki bir değişken ya tanımlanır ya da kullanılır. CFG'de her düğümde değişkenimiz var. Her düğüm, barındırdığı değişken türüne göre adlandırılır. Bir değişken belirli bir düğümde tanımlanırsa, tanımlayıcı bir düğüm oluşturur. Bir düğümde bir değişken kullanılırsa, bir kullanım düğümü oluşturur.
CFG'deki değişken maliyeti dikkate alırsak, bunlar tanımlama ve kullanım düğümleridir:
Düğüm | Tür | Kod |
---|---|---|
1 | Düğümü tanımlama | maliyet = 20 |
5 | Kullanım düğümü | fatura = maliyet -1 |
7 | Kullanım düğümü | fatura = maliyet |
Aşama 3) Tanım kullanım yollarını tanımlayın.
İki tür tanım kullanım yolu vardır: du yolları ve dc yolları. du yolları, bir tanım düğümü ile başlayan ve bir kullanım düğümü ile biten tanım yollarıdır. Yukarıdaki değişken maliyetle ilgili yol için durum budur.
Bir dc yoluna bir örnek, bir karar temizleme yolu, aşağıdaki gibi fatura değişkenine ilişkin yoldur:
Düğüm | Tür | Kod |
---|---|---|
5 | Düğümü tanımlama | fatura = maliyet -1 |
7 | Düğümü tanımlama | fatura = maliyet |
8 | Kullanım düğümü | baskı (fatura) |
dc yolu, bir kullanım düğümünde bitmesine rağmen birden fazla tanım düğümüne sahiptir.
Adım 4) Test paketini oluşturun.
Bu girdi ekliyor. Her değişken için farklı bir test paketimiz olması gerektiğini unutmayın. Test paketi, veri akışı anormalliklerini belirlememize yardımcı olacaktır.
Veri Akışı Test Türleri
İki tip var - Statik ve Dinamik .
Statik, veri anormalliklerini yürütmeden tanımlamak için kod ve CFG'den geçtiğimiz anlamına gelir. Dinamik, belirli yolları gerçekten tanımladığımız ve ardından statik test sırasında kaçırmış olabileceğimiz anormallikleri 'yakalamak' için bir teklifte test etmek üzere test grupları oluşturduğumuz anlamına gelir.
Veri akışı testinin avantajları ve dezavantajları:
- Veri akışı testi, veri akışı anormalliklerini belirlemek için idealdir, bu da onu çok etkili bir yapısal test yöntemi haline getirir.
- Bunun dezavantajı, veri akışı testini kullanmak için kodu yazmak için kullanılan dilde iyi bilgi sahibi olma ihtiyacının olmasıdır. Aynı zamanda zaman alıcıdır.
Yapısal Testin Avantajları ve Dezavantajları
Şimdi yapısal testin neden harika bir yaklaşım olduğunun nedenlerini bulalım ve bazı dezavantajlarını da inceleyelim.
Avantajlar:
- Minimum hatayla sonuçlanan kapsamlı kod testine izin verir. Yapı tabanlı test, yazılımın kapsamlı bir şekilde test edilmesi için yer sağlar. Farklı kapsam düzeyleri - ifadeler, her karar noktası ve yol,% 100 kapsama elde etmeyi hedefler ve bu da hataların tespit edilememe olasılığını büyük ölçüde azaltır.
- Otomatikleştirme yeteneği . Testi otomatikleştirmek için kullanabileceğimiz birkaç araç var. Bu, manuel olarak test yapmaya kıyasla daha kısa sürede ve maksimum kod kapsamına ulaşmamıza yardımcı olacaktır.
- Daha yüksek kaliteli kodla sonuçlanır . Geliştiriciler, kodun yapısını ve uygulamasını inceleme, hataları düzeltme ve bu yönleri iyileştirme şansına sahiptir. Kodun sonraki bölümlerini yazarken veya kalan özellikleri uygularken harika yapıyı aklımızda tutmamızı sağlar.
- SDLC'nin her aşamasında yapılabilir - SDLC'nin her aşamasında, geliştirmenin% 100 tamamlanmasını beklemeden yapısal test yapılabilir. Bu, hataları erken aşamada tespit etmeyi kolaylaştırır ve böylece geliştirme tamamlandıktan sonra teste kıyasla çok zaman kazandırır.
- Ölü kodlardan kurtulmanıza yardımcı olur . Bu, 'ekstra' veya gereksiz kod olarak görülebilir, Örneğin, bir sonucu hesaplayacak ancak aşağıdaki hesaplamaların hiçbirinde asla kullanmayan bir kod.
- Verimlilik - Kodu yazan geliştiriciler, onu test edenler ile aynı olduğundan, QA gibi diğer insanları dahil etmeye gerek yoktur.
Dezavantajları:
- Yapı bazlı test yapan geliştiricilerin dili tam olarak anlaması gerekir. . Dilde çok bilgili olmayan diğer geliştiriciler ve QA'lar testlere yardımcı olamaz.
- Zaman ve para açısından oldukça pahalı hale gelebilir . Testleri verimli bir şekilde yapmak için çok fazla zaman ve kaynak gerekir.
- Özelliklerin sunumunda gecikmelere neden olur . Bunun nedeni, geliştiricilerin test yapmak için yazılım geliştirmekten çekilmesidir.
- Ölçeklendirme, özellikle büyük uygulamaların söz konusu olduğu bir sorundur . Büyük bir uygulama, kapsanacak çok fazla sayıda rotaya eşittir. % 100 kapsama ulaşmak imkansız hale gelir.
- Cevapsız vakalar ve rotalar olabilir , Örneğin, özelliklerin tam olarak geliştirilmediği veya henüz geliştirilmediği bir durumda. Bu, gereksinim testi gibi diğer test türleri ile birleştirilmesi gerektiği anlamına gelir (burada oluşturulması gereken belirli özelliklere karşı kontrol ederiz).
En İyi Yapısal Test Uygulamaları
Yapı bazlı testler yapılırken dikkat edilmesi gereken faktörlerden bazıları şunlardır:
- Testleri açıkça etiketleyin ve adlandırın . Testleri başka birinin yapması gerekiyorsa, onları kolayca bulabilmesi gerekir.
- Kodu geliştirmeden önce, yani yeniden düzenleyerek ve farklı ortamlarda kullanım için optimize etmeden önce yapısının ve akışının ideal olduğundan emin olun.
- Testleri ayrı ayrı çalıştırın . Bu sayede hataları tespit etmek ve düzeltmek kolaydır. Öte yandan, kod bölümleri, blokları veya yollarındaki örtüşmelerin bir sonucu olarak hataları veya yolları gözden kaçırma olasılığımız daha düşüktür.
- Değişiklik yapmadan önce testler oluşturun . Testlerin beklendiği gibi çalışması gerekiyor. Bu şekilde, bir şey kırılırsa, sorunu izlemek ve düzeltmek kolaydır.
- Her bölüm veya kod bloğu için testleri ayrı tutun . Bu şekilde, çizginin altında değişiklikler varsa, çok fazla testi değiştirmemize gerek kalmaz.
- Teste devam etmeden önce hataları düzeltin . Herhangi bir hata tespit edersek, sonraki bölümü veya kod bloğunu test etmeye geçmeden önce bunları düzeltmemiz daha iyi olur.
- Bir KG'nin 'yine de test yapacağı' varsayımıyla yapısal testi asla atlamayın. Hatalar ilk başta önemsiz görünse bile, kümülatif olarak, amaçlanan amacına asla ulaşamayan hatalı kodlarla sonuçlanabilirler.
Yapı Bazlı Test İçin SSS
Burada yapı bazlı testler söz konusu olduğunda sık sorulan soruları inceleyeceğiz.
S # 1) Fonksiyonel test ile yapısal test arasındaki fark nedir?
Cevap: İşlevsel test, SRS'de (Yazılım Gereksinimleri Spesifikasyonları) öngörülen gereksinimlere dayalı bir yazılım testi türüdür. Genellikle, SRS'deki spesifikasyonlar ile kodun nasıl çalıştığı arasındaki farklılıkları bulmak için bir teklifte yapılır. Yapısal test, kodun iç yapısına ve uygulanmasına dayanır. Kodun tam olarak anlaşılması gerekir.
S # 2) Yapısal test türleri nelerdir?
swf dosyası nasıl oynatılır
Cevap: türleri şunları içerir:
- Veri akışı testi
- Mutasyon testi
- Kontrol akışı testi
- Dilim tabanlı test
S # 3) Yapısal test örneği nedir?
Cevap: İşte ifade kapsamını gösteren bir örnek:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();
Aldığımız kapsam miktarı girdi olarak sağladığımız test verilerine (toplam> 0 koşulunu karşılayıp karşılamadığına) bağlıdır.
S # 4) Veri akışı testi ile kontrol akışı testi arasındaki fark nedir?
Cevap: Hem veri akışı testi hem de kontrol akışı testi, kontrol akış grafiklerini kullanır. Tek fark, kontrol akışı testinde koddan oluşturulan yollara odaklanırken, veri akışı testinde veri değerlerine, bunların tanımlarına ve program içinde tanımlanan yollar içindeki kullanımına odaklanıyoruz.
S # 5) Veri akışı testi ne için kullanılır?
Cevap: Veri akışı testi, bir kontrol akış grafiğindeki yollar içinde veri değerlerinin kullanımındaki anormallikleri tanımlamak için idealdir, Örneğin, iki kez değer atanmış bir değişken, tanımlanmış ve kullanılmamış bir değişken veya kullanılmış veya referans alınmış ve tanımlanmamış bir değişken.
S # 6) Yazılım testinde dilimleme ve dilimleme arasındaki fark nedir?
Cevap: Dilimleme, bir programdaki belirli ilgi ifadelerine odaklanmak ve geri kalanını göz ardı etmek anlamına gelir. Parçalama, yanlış girişe sahip bir dilimi belirlediğimizde ve ardından doğru davranışı izlemek için daha fazla dilimlememizdir.
S # 7) Mutasyon testi ile kod kapsamı arasındaki fark nedir?
Cevap: Mutasyon testinde, öldürülen mutantların sayısını toplam mutantların yüzdesi olarak ele alıyoruz. Kod kapsamı, bir programda test edilen kod miktarıdır.
Sonuç
Bu eğiticide yapısal testlere derinlemesine baktık - ne olduğu, ne olmadığı, nasıl devam edileceği, kapsam türleri, avantajları ve dezavantajları, en iyi uygulamalar ve hatta bu yazılım test türü ile ilgili bazı SSS'ler.
Yapı bazlı test hakkında öğrenebileceğimiz daha çok şey var. Gelecekteki eğitimlerde, kod kapsamını (ifade, karar, dal ve yol), yapısal test türlerini (mutasyon, veri akışı ve dilim tabanlı) ve hatta bu test süreçlerini otomatikleştirmek için kullanabileceğimiz araçları keşfedeceğiz.
% 100 verimli olan herhangi bir yazılım test türü veya yaklaşımı olmadığına dikkat etmek önemlidir. Her zaman farklı test türlerini ve yaklaşımlarını birleştirmeniz önerilir.
Örneğin, Yapısal testler, yapı temelli testlerin gerçekleştirildiği sırada geliştirilmemiş olabilecek özellikler olabileceğinden, gereksinim testleri ile büyük ölçüde tamamlanmaktadır.
Yapısal test teknikleri, insan programcıların kod yazarken yaptıkları hatalara dayanır. Varsayım, programcının bir uzman olduğu ve neyi kodladığını bildiği, ancak zaman zaman hata yaptığıdır.
Baktığımız farklı yapısal test türleri - mutasyon testi, dilim tabanlı test ve veri akışı testi, yanlış operatör kullanma (mutasyon testi) veya kullanmadan önce bir değişkeni referans alma (veri akışı testi) gibi hatalara kadar geriye doğru izlenebilir. .
Önerilen Kaynaklar
- Yıkıcı Muayene ve Tahribatsız Muayene Eğitimi
- Fonksiyonel Test ve Fonksiyonel Olmayan Test
- Kusur Temelli Test Tekniği Nedir?
- Islatma Testi Eğitimi - Islanma Testi Nedir?
- SOA Test Eğitimi: SOA Mimari Modeli İçin Test Metodolojisi
- HP LoadRunner Öğreticileriyle Yük Testi
- Gama Testi nedir? Son Test Aşaması
- DevOps Test Eğitimi: DevOps, KG Testini Nasıl Etkileyecek?
- Uyumluluk Testi (Uygunluk testi) nedir?