SIT nedir? (Örneklerle Sistem Entegrasyon Testi)

Sistem Entegrasyon Testi Nedir?

sistem Entegrasyon Testi tüm sistemin davranışını doğrulamak için entegre bir donanım ve yazılım ortamında gerçekleştirilen bir tür yazılım testi olarak tanımlanır. Sistemin belirlenen gereksinimlere uygunluğunu değerlendirmek amacıyla eksiksiz, entegre bir sistem üzerinde yapılan testlerdir.

Bir yazılım sisteminin modülleri arasındaki etkileşimleri doğrulamak için Sistem Entegrasyon Testi (SIT) yapılır. Yazılım Gereksinimleri Belirtimi/Verileri ve Yazılım Tasarım Dokümanında belirtilen yüksek ve düşük seviyeli yazılım gereksinimlerinin doğrulanması ile ilgilenir.

SIT ayrıca bir yazılım sisteminin diğerleriyle birlikte çalışabilirliğini doğrular ve yazılım uygulamasının modülleri arasındaki arayüzü test eder. Bu test türünde, modüller önce ayrı ayrı test edilir ve daha sonra bir sistem oluşturmak üzere birleştirilir. Örneğin, yazılım ve/veya donanım bileşenleri birleştirilir ve tüm sistem entegre edilene kadar aşamalı olarak test edilir.

Yukarıdaki diyagram, SIT'i tanımlayan ilerlemeyi göstermektedir: ayrı ayrı doğrulanmış modüller, tek bir entegre sistem test edilene kadar adım adım birleştirilir.

Sistem Entegrasyon Testi neden yapılır?

Yazılım Mühendisliğinde Sistem Entegrasyon Testi yapılır çünkü,

• Tespit etmeye yardımcı olur kusur erken
• Bireysel modülün kabul edilebilirliğine ilişkin daha önceden geri bildirim sağlanacaktır.
• Kusur düzeltmelerinin planlanması esnektir ve geliştirme süreciyle örtüşebilir
• Doğru veri akışı
• Doğru kontrol akışı
• Doğru zamanlama
• Doğru bellek kullanımı
• Yazılım gereksinimlerine uygun

Sistem Entegrasyon Testi, Sistem Testi ve Kullanıcı Kabul Testi Arasındaki Farklar

Bu üç seviye art arda geldiği için sıklıkla karıştırılırlar. Sistem Testi SIT, tamamlanmış bir yapıyı gereksinimlerine göre incelerken, yapılar arasındaki bağlantıları inceler. kullanıcı Kabul Testi İşletmenin müşteri bakış açısından uygunluğunu inceler. Aşağıdaki tablo bunları birbirinden ayırır.

Parametre	Sistem Entegrasyon Testi	Sistem Testi	kullanıcı Kabul Testi
Birincil odak	Entegre modüller arasındaki arayüzler ve veri akışı	Bir araya getirilmiş yapının bir bütün olarak davranışı	Gerçek kullanım için iş amaçlı fitness
Test seviyesi	seviye iki	Üçüncü seviye	Canlı yayına geçmeden önceki son aşama
Teknik	Siyah kutu	Siyah kutu, beyaz kutu veya gri kutu	Siyah kutu
Tarafından gerçekleştirilen	Entegrasyon test uzmanları ve geliştiriciler	Bağımsız test ekibi	Müşteri veya son kullanıcılar
Tipik kusurlar	Arayüz, zamanlama, bellek ve veri haritasıping hataları	İşlevsel ve işlevsel olmayan sistem hataları	Kullanılabilirlik ve gereksinim uyumsuzlukları
Çalıştırıldığında	Sonra Birim Testi	SIT'ten sonra	Sistem Testinden Sonra

Sıralama önemlidir. Modüller birim testini geçer, SIT arayüzleri doğrular, Sistem Testi monte edilmiş ürünü doğrular ve UAT ürünün iş beklentilerine uygunluğunu onaylar. Atlaping SIT, arayüz hatalarını UAT'ye (kullanıcı kabul testine) iter ve burada her düzeltmenin maliyeti çok daha yüksek olur.

Sistem Entegrasyon Testi nasıl yapılır

Bu, arayüzle ilgili hataları ortaya çıkarmak için testler yapılırken program yapısını oluşturmaya yönelik sistematik bir tekniktir.

Tüm modüller önceden entegre edilir ve programın tamamı bir bütün olarak test edilir. Ancak bu süreçte bir takım hatalarla karşılaşılması muhtemeldir.

Bu tür hataların düzeltilmesi zordur çünkü izolasyon nedenleri, tüm programın geniş genişlemesi nedeniyle karmaşık hale gelir. Bu hatalar düzeltilip düzeltildikten sonra yenisi ortaya çıkacak ve süreç sonsuz bir döngü içinde sorunsuz bir şekilde devam edecektir.. Bu durumdan kaçınmak için başka bir yaklaşım kullanılır: Artımlı Entegrasyon. Artımlı yaklaşım bir sonraki bölümde ayrıntılı olarak açıklanmaktadır.

Entegrasyon testlerinin hedef işlemciye dayalı bir sistem üzerinde yapılması gibi artımlı yöntemler vardır. Kullanılan metodoloji Siyah Box Test yapmak. Aşağıdan yukarıya veya yukarıdan aşağıya entegrasyon kullanılabilir.

Test senaryoları yalnızca üst düzey yazılım gereksinimleri kullanılarak tanımlanır.

Yazılım entegrasyonu büyük ölçüde ana bilgisayar ortamında da gerçekleştirilebilir; hedef ortama özgü birimler ana bilgisayarda simüle edilmeye devam edilir. Onay için hedef ortamda testlerin tekrarlanması yine gerekli olacaktır.

Bu seviyedeki doğrulama testleri, bellek tahsisi ve serbest bırakılmasındaki hatalar gibi ortama özgü sorunları belirleyecektir. Ana ortamda yazılım entegrasyonunun uygulanabilirliği, hedef ortama özgü işlevselliğin ne kadar olduğuna bağlı olacaktır. Bazı gömülü sistemler için hedef ortamla olan bağlantı çok güçlü olacak ve bu da ana ortamda yazılım entegrasyonunu pratik olmaktan çıkaracaktır.

Büyük yazılım geliştirmeleri yazılım entegrasyonunu bir dizi seviyeye bölecektir. Yazılım entegrasyonunun daha düşük seviyeleri ağırlıklı olarak ana bilgisayar ortamına dayanabilirken, yazılım entegrasyonunun daha sonraki seviyeleri hedef ortama daha bağımlı hale gelebilir.

Not: Yalnızca yazılım test ediliyorsa Yazılım Yazılım Entegrasyon Testi [SSIT], hem donanım hem de yazılım test ediliyorsa Donanım Yazılım Entegrasyon Testi [HSIT] olarak adlandırılır.

Artımlı Yaklaşım

Her şeyi aynı anda entegre etmek hataları tespit etmeyi zorlaştırdığı için, çoğu ekip burada açıklanan aşamalı yöntemi izler.

Artımlı test, entegrasyon testinin bir yoludur. Bu tür test yönteminde, önce yazılımın her modülünü ayrı ayrı test edersiniz, ardından ona diğer modülleri, ardından başka bir modülü ekleyerek teste devam edersiniz.

Artımlı entegrasyon, büyük patlama yaklaşımının tam tersidir. Program, hataların izole edilmesinin ve düzeltilmesinin daha kolay olduğu küçük bölümler halinde oluşturulmuş ve test edilmiştir. Arayüzlerin tamamen test edilme olasılığı daha yüksektir ve sistematik bir test yaklaşımı uygulanabilir.

İki tür Artımlı test vardır

• Yukarıdan aşağıya yaklaşım
• Aşağıdan Yukarıya yaklaşım

Yukarıdan Aşağıya Yaklaşım

Bu tür bir yaklaşımda, bireysel olarak, temel işlevsellik taslaklar tarafından simüle edilerek yalnızca kullanıcı arayüzünü test ederek başlar, ardından aşağıdaki resimde gösterildiği gibi alt ve alt katmanları entegre ederek aşağıya doğru hareket edersiniz.

• Ana kontrol modülünden başlayarak modüller, kontrol hiyerarşisinde aşağıya doğru ilerleyerek entegre edilir
• Ana kontrol modülünün alt modülleri yapıya ya genişlik öncelikli ya da derinlik öncelikli olacak şekilde dahil edilmiştir.
• Derinlik öncelikli entegrasyon, aşağıdaki diyagramda gösterildiği gibi yapının ana kontrol yolundaki tüm modülleri entegre eder:

Modül entegrasyon süreci aşağıdaki şekilde gerçekleştirilir:

1. Ana kontrol modülü bir test sürücüsü olarak kullanılır ve taslaklar doğrudan ana kontrol modülüne bağlı tüm modüllerin yerine geçer.
2. İkincil taslaklar, seçilen yaklaşıma (önce genişlik veya önce derinlik) bağlı olarak gerçek modüllerle teker teker değiştirilir.
3. Her modül entegre edildiğinde testler gerçekleştirilir.
4. Her test kümesinin tamamlanmasının ardından, her test kümesinin tamamlanmasının ardından başka bir taslak, gerçek bir modülle değiştirilir.
5. Yeni hataların ortaya çıkmadığından emin olmak için Gerileme testi yapılabilir.

Süreç 2. adımdan tüm program yapısı oluşturulana kadar devam eder. Yukarıdan aşağıya strateji nispeten basit gibi görünse de pratikte lojistik sorunlar ortaya çıkıyor.

Bu sorunlardan en yaygın olanı, hiyerarşideki alt düzeylerde işlem yapılmasının üst düzeyleri yeterince test etmek için gerekli olduğu durumlarda ortaya çıkar.

Saplamalar, yukarıdan aşağıya testin başlangıcında düşük seviyeli modüllerin yerini alır ve bu nedenle program yapısında yukarıya doğru önemli bir veri akamaz.

Testçinin karşılaşabileceği zorluklar:

• Taslaklar gerçek modüllerle değiştirilene kadar birçok testi erteleyin.
• Gerçek modülü simüle eden sınırlı işlevleri gerçekleştiren taslaklar geliştirin.
• Yazılımı hiyerarşinin en altından yukarıya doğru entegre edin.

Not: İlk yaklaşım, belirli testler ile belirli modüllerin dahil edilmesi arasındaki yazışmalar üzerindeki kontrolümüzün bir kısmını kaybetmemize neden olur. Bu, yukarıdan aşağıya yaklaşımın son derece kısıtlı doğasını ihlal eden hataların nedeninin belirlenmesinde zorlukla sonuçlanabilir.

İkinci yaklaşım işe yarayabilir ancak taslaklar giderek daha karmaşık hale geldikçe önemli bir ek yüke yol açabilir.

Aşağıdan Yukarıya Yaklaşım

Aşağıdan yukarıya entegrasyon, program yapısındaki en alt seviyedeki modüllerle inşaat ve teste başlar. Bu süreçte modüller aşağıdan yukarıya doğru entegre edilir.

Bu yaklaşımda, belirli bir seviyeye bağlı modüller için gereken işlemler her zaman mevcuttur ve taslaklara olan ihtiyaç ortadan kaldırılmıştır.

Bu entegrasyon testi süreci dört adımdan oluşan bir seri halinde gerçekleştirilir

1. Düşük seviyeli modüller, belirli bir yazılım alt işlevini gerçekleştiren kümeler halinde birleştirilir.
2. Test senaryosu giriş ve çıkışını koordine etmek için bir sürücü yazılmıştır.
3. Küme veya yapı test edilir.
4. Sürücüler kaldırılır ve kümeler, program yapısında yukarı doğru hareket ederek birleştirilir.

Entegrasyon yukarı doğru ilerledikçe, ayrı test sürücülerine duyulan ihtiyaç azalır. Aslında, program yapısının en üst iki seviyesi yukarıdan aşağıya doğru entegre edilirse, sürücü sayısı önemli ölçüde azaltılabilir ve kümelerin entegrasyonu büyük ölçüde basitleştirilebilir. Entegrasyon, aşağıda gösterilen modeli izler.

Not: Program yapısının en üst iki seviyesi Yukarıdan aşağıya entegre edilirse, sürücü sayısı önemli ölçüde azaltılabilir ve yapıların entegrasyonu büyük ölçüde basitleştirilir.

Büyük Patlama Yaklaşımı

Bu yaklaşımda, tüm modüller hazır olana kadar ve hazır olmadıkça tüm modüller entegre edilmez. Hazır olduklarında tüm modüller entegre edilir ve ardından tüm entegre modüllerin çalışıp çalışmadığını öğrenmek için çalıştırılır.

Bu yaklaşımda her şeyin bir kerede entegre edilmesi nedeniyle başarısızlığın temel nedenini bilmek zordur.

Ayrıca üretim ortamında kritik hataların ortaya çıkma olasılığı da yüksek olacaktır.

Bu yaklaşım yalnızca entegrasyon testinin bir kerede yapılması gerektiğinde benimsenir.

Donanım Yazılım Entegrasyon Testi

Donanım Yazılım Entegrasyon Testi Hedef donanım ortamındaki üst düzey işlevler açısından Bilgisayar Yazılım Bileşenlerini (CSC) test etme sürecidir. Donanım/yazılım entegrasyon testinin amacı, geliştirilen yazılımın donanım bileşenine entegre edilmiş davranışını test etmektir.

Gereksinim Bazlı Donanım-Yazılım Entegrasyon Testi

Gereksinim tabanlı donanım/yazılım entegrasyon testinin amacı, hedef bilgisayardaki yazılımın üst düzey gereksinimleri karşıladığından emin olmaktır. Bu test yöntemiyle ortaya çıkan tipik hatalar şunları içerir:

• Donanım/yazılım arayüz hataları
• Yazılım bölümleme ihlalleri.
• Yerleşik testle arızaların tespit edilememesi
• Donanım arızalarına yanlış yanıt
• Sıralama, geçici giriş yükleri ve giriş gücü geçişlerinden kaynaklanan hata
• Geri bildirim yanlış davranışı döngüye sokar
• Bellek yönetimi donanımının yanlış veya hatalı kontrolü
• Veri yolu çekişme sorunu
• Sahada yüklenebilir yazılımın uyumluluğunu ve doğruluğunu doğrulamaya yönelik mekanizmanın yanlış çalışması

Donanım Yazılım Entegrasyonu, üst düzey gereksinimlerin doğrulanmasıyla ilgilenir. Bu seviyedeki tüm testler hedef donanım üzerinde gerçekleştirilir.

• Bu test seviyesinde kullanılan temel test metodolojisi kara kutu testidir.
• Tanımlama test senaryoları yalnızca üst düzey gereksinimlerden
• Üretim standardı donanımında (hedefte) bir test yürütülmelidir

Donanım/Yazılım Entegrasyonu için test senaryoları tasarlarken dikkate alınması gereken noktalar

• Yazılım tarafından tüm verilerin doğru şekilde elde edilmesi
• Donanımdan yazılıma beklendiği gibi ölçeklendirme ve veri aralığı
• Yazılımdan donanıma doğru veri çıkışı
• Spesifikasyonlar dahilindeki veriler (normal aralık)
• Spesifikasyonların dışındaki veriler (anormal aralık)
• Sınır verileri
• İşlemeyi kesintiye uğratır
• Zamanlama
• Doğru bellek kullanımı (adresleme, çakışmalar vb.)
• Durum geçişleri

Not: Kesinti testi için tüm kesintiler, ilk talepten tam hizmete ve tamamlamaya kadar bağımsız olarak doğrulanacaktır. Kesintileri yeterince test etmek için test senaryoları özel olarak tasarlanacaktır.

Yazılımdan Yazılıma Entegrasyon Testi

Bu, bilgisayar yazılım bileşeninin (CSC) ana/hedef bilgisayar ortamında çalışmasının, tüm sistemi [diğer CSC'leri] simüle ederken ve üst düzey işlevselliği test etmesidir.

Bu, simüle edilmiş bir ana bilgisayar/hedef ortamında bir CSC'nin davranışına odaklanır. Yazılım Entegrasyonu için kullanılan yaklaşım, artımlı bir yaklaşım (yukarıdan aşağıya, aşağıdan yukarıya veya her ikisinin birleşimi, ayrıca sandviç veya hibrit yaklaşım olarak da adlandırılır) olabilir.

Entegrasyon Testine Giriş ve Çıkış Kriterleri

Yaklaşım ve iki entegrasyon varyantı belirlendikten sonra, geriye kalan soru bir ekibin ne zaman başlayıp ne zaman durabileceğidir. Genellikle Entegrasyon Testi yapılırken ETVX (Giriş Kriterleri, Görev, Doğrulama ve Çıkış Kriterleri) stratejisi kullanılır.

Giriş Kriterleri:

• Tamamlanması Birim Testi

Girişler:

• Yazılım Gereksinimleri Verileri
• Yazılım Tasarım Belgesi
• Yazılım Doğrulama Planı
• Yazılım Entegrasyon Belgeleri

Etkinlikler:

• Yüksek ve Düşük seviye gereksinimlerine dayanarak test senaryoları ve prosedürler oluşturun
• Ortak bir işlevsellik uygulayan düşük seviyeli modül yapılarını birleştirin
• Bir test koşum takımı geliştirin
• Yapıyı test edin
• Test geçildikten sonra yapı diğer yapılarla birleştirilir ve sistem bir bütün olarak entegre olana kadar test edilir.
• Hedef işlemci tabanlı platformda tüm testleri yeniden gerçekleştirin ve sonuçları alın

Kriterlerden Çık:

• Yazılım modülünün hedef donanıma entegrasyonu başarıyla tamamlandı
• Belirtilen gereksinimlere göre yazılımın doğru performansı

Çıkışlar

• Entegrasyon test raporları
• Yazılım Test Durumları ve Prosedürleri [SVCP].

Sistem Entegrasyon Testlerinde Sık Karşılaşılan Zorluklar

Sağlam bir yaklaşım ve net çıkış kriterlerine sahip olsanız bile, entegre ortamlar, birim testleri sırasında asla ortaya çıkmayan sorunlar yaratır. Bunları erken fark etmek, zaman çizelgesini gerçekçi tutar.

• Çevresel uyumsuzluk: entegre test ortamı Üretim sürecini nadiren yansıtır, bu nedenle zamanlama ve yapılandırma hataları çok geç bir aşamaya kadar fark edilmez.
• Bağımlılığa hazır olma durumu: Üçüncü taraf ve eski arayüzler genellikle tamamlanmamış halde bulunur ve bu durum test uzmanlarının planlanandan çok daha uzun süre simülatörlere ve geçici çözümlere güvenmelerine neden olur.
• Veri tutarsızlığı: İki modül aynı kaydı farklı şekilde temsil edebilir ve bu da görünür hatalar yerine sessiz uyumsuzluklara yol açabilir.
• Hata sahipliği: Bir arıza iki ekibi de etkilediğinde, kök neden analizi ve kusur yönetimi Gözle görülür şekilde yavaşlayın.
• Gerileme maliyeti: her yeni arayüz genişletiyor gerileme testi Bu nedenle, manuel yeniden çalıştırma işlemi kısa sürede sürdürülemez hale gelir.

Bunların çoğu teknik çıkmazlardan ziyade zamanlama riskleridir. İlk derleme entegre edilmeden önce arayüz hazır olma tarihleri, simülatör kapsamı ve hata ayıklama sorumluluğu konusunda anlaşmaya varılması, bunların büyük çoğunluğunu ortadan kaldırır. Tedarikçiye ait arayüzler için, kararlaştırılan mesaj formatını ve bir üst düzey iletişim kişisini de kaydedin, çünkü eksik bir sorumlu, hatanın gerektirdiğinden daha uzun süre düzeltmeyi geciktirir.

Sistem Entegrasyon Testi için En İyi Uygulamalar

Tekrarlanabilir bir sistem entegrasyon testi (SIT) döngüsü, araçlardan ziyade arayüzler, veriler ve kanıtlar etrafındaki disipline bağlıdır. Aşağıdaki beş uygulama, küçük bir gömülü sistemden büyük, çok tedarikçili bir ortama kadar her iki duruma da uygundur ve her biri daha sonraki test seviyelerine ulaşan yeniden çalışma ihtiyacını azaltır.

1. Öncelikle tüm arayüzleri eşleştirin. Tek bir test senaryosu yazmadan önce, her veri alışverişini, yönünü, protokolünü ve sahibini listeleyin.
2. Risk düzeyine göre önceliklendirin. Kozmetik ürünlerle ilgili arayüzlerden önce, para, kimlik veya düzenlemeye tabi verileri taşıyan arayüzleri doğrulayın.
3. Gerçekçi test verileri tasarlayın. Ölçekleme ve yuvarlama hatalarının erken ortaya çıkması için normal, sınır ve anormal aralıkları kapsayın.
4. İstikrarlı yolları otomatikleştirin. Kablo arayüzü kontrolleri bir sürekli entegrasyon Bu sayede her derleme işlemi bunları yeniden doğrular.
5. Kanıtları saklayın tracmümkün. Her sonucu bir gereksinime şu şekilde bağlayın: tracyetenek matrisi Dolayısıyla çıkış kriterleri iddia edilemez, ispatlanabilir.

⚠ İpucu: Entegrasyon başlamadan önce arayüz özelliklerini dondurun. Mesaj formatında yapılan geç bir değişiklik, arayüzün her iki tarafındaki test senaryolarını geçersiz kılar ve sistem entegrasyon testinin yeniden işlenmesinin en yaygın nedenidir.

SSS