Mikä on SIT? Järjestelmäintegraatiotestaus esimerkin avulla

Mitä on järjestelmäintegraatiotestaus?

järjestelmä Integraation testaus on määritelty ohjelmistotestaukseksi, joka suoritetaan integroidussa laitteisto- ja ohjelmistoympäristössä koko järjestelmän toiminnan tarkistamiseksi. Se testataan täydellisellä integroidulla järjestelmällä sen arvioimiseksi, täyttääkö järjestelmä sen määritetyt vaatimukset.

Järjestelmäintegraatiotestaus (SIT) suoritetaan ohjelmistojärjestelmän moduulien välisten vuorovaikutusten varmentamiseksi. Se käsittelee ohjelmistovaatimusten määrittelyssä/tiedoissa ja ohjelmistosuunnitteludokumentissa määriteltyjen korkean ja matalan tason ohjelmistovaatimusten varmentamista.

SIT varmistaa myös ohjelmistojärjestelmän rinnakkaiselon muiden kanssa ja testaa ohjelmistosovelluksen moduulien välisen rajapinnan. Tällaisessa testauksessa moduulit testataan ensin yksittäin ja yhdistetään sitten järjestelmän muodostamiseksi. Esimerkiksi ohjelmisto- ja/tai laitteistokomponentteja yhdistetään ja testataan asteittain, kunnes koko järjestelmä on integroitu.

Yllä oleva kaavio näyttää SIT:n määrittelevän etenemisen: erikseen varmennetut moduulit yhdistetään askel askeleelta, kunnes jäljellä on yksi integroitu testattava järjestelmä.

Miksi järjestelmäintegraatiotestaus?

Ohjelmistosuunnittelussa järjestelmäintegraatiotestaus tehdään, koska

• Se auttaa havaitsemaan Vika varhainen
• Aiempaa palautetta yksittäisen moduulin hyväksyttävyydestä on saatavilla
• Viankorjausten ajoitus on joustavaa, ja se voi olla päällekkäinen kehitystyön kanssa
• Oikea tiedonkulku
• Oikea ohjausvirtaus
• Oikea ajoitus
• Oikea muistin käyttö
• Ohjelmistovaatimusten mukainen

Järjestelmäintegraatiotestaus vs. järjestelmätestaus vs. käyttäjän hyväksyntätestaus

Koska nämä kolme tasoa kulkevat peräkkäin, ne sekoitetaan usein. Järjestelmän testaus tutkii yhden valmiin rakennelman vaatimusten mukaisesti, SIT tutkii rakennelmien väliset saumat ja Käyttäjien hyväksyntätestaus tarkastelee liiketoiminnan soveltuvuutta asiakkaan näkökulmasta. Alla oleva taulukko erottelee ne toisistaan.

Parametri	Järjestelmäintegraation testaus	Järjestelmän testaus	Käyttäjien hyväksyntätestaus
Ensisijainen painopiste	Integroitujen moduulien väliset rajapinnat ja tiedonkulku	Kootun rakenteen käyttäytyminen kokonaisuutena	Liiketoiminnan kunto tosielämän käyttöön
Testaustaso	Taso kaksi	Taso kolme	Viimeinen taso ennen käyttöönottoa
Tekniikka	Musta laatikko	Musta laatikko, valkoinen laatikko tai harmaa laatikko	Musta laatikko
Esittäjä	Integraatiotestaajat ja -kehittäjät	Riippumaton testausryhmä	Asiakas tai loppukäyttäjät
Tyypillisiä vikoja	Rajapinta, ajoitus, muisti ja datakarttaping virheet	Toiminnalliset ja ei-toiminnalliset järjestelmävirheet	Käytettävyyden ja vaatimusten epäsuhta
Toimii, kun	Jälkeen Yksikkötestaus	SIT:n jälkeen	Järjestelmätestauksen jälkeen

Järjestyksellä on väliä. Moduulit läpäisevät yksikkötestauksen, SIT varmistaa rajapintojen toimivuuden, järjestelmätestaus varmistaa kootun tuotteen toimivuuden ja UAT varmistaa, että tuote vastaa liiketoiminnan odotuksia.ping SIT työntää rajapintavirheet käyttäjäavusteiseen arviointiin (UAT), jossa jokainen korjaus maksaa paljon enemmän.

Kuinka tehdä järjestelmäintegraatiotestaus

Se on systemaattinen tekniikka ohjelmarakenteen rakentamiseen samalla, kun suoritetaan testejä rajapintoihin liittyvien virheiden paljastamiseksi.

Kaikki moduulit integroidaan etukäteen ja koko ohjelma testataan kokonaisuutena. Mutta tämän prosessin aikana tulee todennäköisesti joukko virheitä.

Tällaisten virheiden korjaaminen on vaikeaa, koska syiden eristämistä vaikeuttaa koko ohjelman laaja laajennus. Kun nämä virheet on korjattu ja korjattu, uusi tulee näkyviin ja prosessi jatkuu saumattomasti loputtomassa silmukassa. Tämän tilanteen välttämiseksi käytetään toista lähestymistapaa, inkrementaalista integrointia. Inkrementaalista lähestymistapaa selitetään yksityiskohtaisesti seuraavassa osiossa.

On olemassa joitain inkrementaalisia menetelmiä, kuten integrointitestit suoritetaan kohdeprosessoriin perustuvassa järjestelmässä. Käytetty metodologia on Musta Box Testaus. Voidaan käyttää joko alhaalta ylös tai ylhäältä alas -integrointia.

Testitapaukset määritellään käyttämällä vain korkean tason ohjelmistovaatimuksia.

Ohjelmistointegraatio voidaan myös saavuttaa suurelta osin isäntäympäristössä, jolloin kohdeympäristöön liittyviä yksiköitä simuloidaan edelleen isäntäkoneessa. Testien toistaminen kohdeympäristössä vahvistusta varten on jälleen tarpeen.

Tämän tason varmistustestit tunnistavat ympäristökohtaisia ​​ongelmia, kuten virheitä muistin allokoinnissa ja allokoinnin purkamisessa. Ohjelmistointegraation käytännöllisyys isäntäympäristössä riippuu siitä, kuinka paljon kohdekohtaista toiminnallisuutta on. Joissakin sulautetuissa järjestelmissä kytkentä kohdeympäristöön on erittäin vahva, mikä tekee ohjelmistointegraation suorittamisesta isäntäympäristössä epäkäytännöllistä.

Suuret ohjelmistokehitykset jakavat ohjelmistointegraation useille tasoille. Ohjelmistointegraation alemmat tasot voisivat perustua pääasiassa isäntäympäristöön, ja myöhemmät ohjelmistointegraation tasot tulevat entistä riippuvaisemmiksi kohdeympäristöstä.

Huomautus: Jos vain ohjelmistoa testataan, sitä kutsutaan Software Software Integration Testing [SSIT]ksi ja jos testataan sekä laitteistoa että ohjelmistoa, sitä kutsutaan Hardware Software Integration Testing [HSIT]ksi.

Inkrementaalinen lähestymistapa

Koska kaiken integrointi kerralla tekee vikojen eristämisestä vaikeaa, useimmat tiimit noudattavat tässä kuvattua inkrementaalista reittiä.

Inkrementaalinen testaus on tapa integraatiotestaukseen. Tämän tyyppisessä testausmenetelmässä testataan ensin jokainen ohjelmiston moduuli yksitellen ja sitten jatketaan testausta lisäämällä siihen muita moduuleja, sitten toinen ja niin edelleen.

Inkrementaalinen integraatio on vastakohta big bang -lähestymistapalle. Ohjelma on rakennettu ja testattu pienissä segmenteissä, joissa virheet on helpompi eristää ja korjata. Liitännät testataan todennäköisemmin kokonaan, ja järjestelmällistä testausmenetelmää voidaan soveltaa.

Inkrementaalista testausta on kahta tyyppiä

• Ylhäältä alas -lähestymistapa
• Alhaalta ylös -lähestymistapa

Ylhäältä alas -lähestymistapa

Tämän tyyppisessä lähestymistavassa yksittäinen aloitetaan testaamalla vain käyttöliittymä, jonka taustalla oleva toiminnallisuus simuloidaan tyngillä, ja sitten siirrytään alaspäin integroimalla alemmat ja alemmat kerrokset alla olevan kuvan mukaisesti.

• Pääohjausmoduulista alkaen moduulit integroidaan siirtymällä alaspäin ohjaushierarkiassa
• Pääohjausmoduulin alimoduulit on liitetty rakenteeseen joko leveys- tai syvyys-ensimmäisellä tavalla.
• Syvyys ensin -integrointi integroi kaikki moduulit rakenteen pääohjauspolulle seuraavan kaavion mukaisesti:

Moduulien integrointiprosessi suoritetaan seuraavalla tavalla:

1. Pääohjausmoduulia käytetään testiajurina, ja tyngät korvataan kaikissa suoraan pääohjausmoduulin alaisissa moduuleissa.
2. Alisteiset osat korvataan yksi kerrallaan todellisilla moduuleilla valitun lähestymistavan mukaan (leveys ensin tai syvyys ensin).
3. Testit suoritetaan, kun jokainen moduuli on integroitu.
4. Kunkin testisarjan päätyttyä toinen osa korvataan oikealla moduulilla kunkin testisarjan päätyttyä
5. Varmistetaan, ettei uusia virheitä ole tullut Regressiotestaus voidaan suorittaa.

Prosessi jatkuu vaiheesta 2, kunnes koko ohjelmarakenne on rakennettu. Ylhäältä alas -strategia kuulostaa suhteellisen yksinkertaiselta, mutta käytännössä syntyy logistisia ongelmia.

Yleisimmät näistä ongelmista ilmenevät, kun hierarkian alhaisilla tasoilla käsittelyä vaaditaan ylempien tasojen testaamiseksi riittävästi.

Stubit korvaavat matalan tason moduulit ylhäältä alas -testauksen alussa, joten merkittävää dataa ei voi virrata ylöspäin ohjelmarakenteessa.

Testaajan kohtaamat haasteet:

• Viivytä monia testejä, kunnes tyngät korvataan todellisilla moduuleilla.
• Kehitä typpejä, jotka suorittavat rajoitettuja toimintoja, jotka simuloivat varsinaista moduulia.
• Integroi ohjelmisto hierarkian alhaalta ylöspäin.

Huomautus: Ensimmäinen lähestymistapa aiheuttaa sen, että menetämme jonkin verran hallintaa tiettyjen testien ja tiettyjen moduulien välisen vastaavuuden suhteen. Tämä voi johtaa vaikeuksiin virheiden syyn määrittämisessä, mikä yleensä rikkoo ylhäältä alas -lähestymistavan erittäin rajoitettua luonnetta.

Toinen lähestymistapa on toimiva, mutta se voi johtaa merkittäviin yleiskustannuksiin, koska tyngät muuttuvat yhä monimutkaisemmiksi.

Alhaalta ylöspäin -lähestymistapa

Alhaalta ylös -integrointi aloittaa rakentamisen ja testauksen moduulien alimmalla tasolla ohjelmarakenteessa. Tässä prosessissa moduulit integroidaan alhaalta ylös.

Tässä lähestymistavassa tietyn tason alisteisille moduuleille tarvittava prosessointi on aina saatavilla ja tynkien tarve jää pois.

Tämä integrointitestiprosessi suoritetaan neljän vaiheen sarjassa

1. Matalan tason moduulit yhdistetään klustereiksi, jotka suorittavat tietyn ohjelmiston alitoiminnon.
2. Ajuri on kirjoitettu koordinoimaan testitapauksen tuloa ja tulosta.
3. Klusteri tai rakennelma testataan.
4. Ajurit poistetaan ja klusterit yhdistetään siirtymällä ylöspäin ohjelmarakenteessa.

Integraation edetessä ylöspäin tarvitaan erillisiä ajurioppitunteja. Itse asiassa, jos ohjelmarakenteen kaksi ylintä tasoa integroidaan ylhäältä alaspäin, ajurien määrää voidaan vähentää huomattavasti ja klusterien integrointi yksinkertaistuu huomattavasti. Integrointi noudattaa alla esitettyä kaavaa.

Huomautus: Jos ohjelmarakenteen kaksi ylintä tasoa integroidaan ylhäältä alas, ohjainten määrää voidaan vähentää merkittävästi ja koontiversioiden integrointi yksinkertaistuu huomattavasti.

Big Bang -lähestymistapa

Tässä lähestymistavassa kaikkia moduuleja ei integroida ennen kuin kaikki moduulit ovat valmiita. Kun ne ovat valmiit, kaikki moduulit integroidaan ja sitten se suoritetaan, jotta tiedetään, toimivatko kaikki integroidut moduulit vai eivät.

Tässä lähestymistavassa on vaikea tietää vian perimmäistä syytä, koska kaikki integroidaan kerralla.

Lisäksi tuotantoympäristössä on suuri mahdollisuus kriittisten virheiden esiintymiseen.

Tämä lähestymistapa omaksutaan vain, kun integrointitestaus on suoritettava kerralla.

Laitteiston ohjelmistointegraation testaus

Laitteiston ohjelmistointegraation testaus on prosessi, jossa testataan tietokoneohjelmistokomponenttien (CSC) korkean tason toimintoja kohdelaitteistoympäristössä. Laitteiston/ohjelmiston integraatiotestauksen tavoitteena on testata laitteistokomponenttiin integroidun kehitetyn ohjelmiston käyttäytymistä.

Vaatimuspohjainen laitteisto-ohjelmisto integraatiotestaus

Vaatimuspohjaisen laitteiston/ohjelmiston integraatiotestauksen tavoitteena on varmistaa, että kohdetietokoneen ohjelmisto täyttää korkean tason vaatimukset. Tyypillisiä tämän testausmenetelmän paljastamia virheitä ovat:

• Laitteiston/ohjelmiston rajapintojen virheet
• Ohjelmistojen osioinnin rikkomukset.
• Kyvyttömyys havaita vikoja sisäänrakennetulla testillä
• Väärä vastaus laitteistohäiriöihin
• Sekvensoinnista, transienttitulokuormista ja syöttötehotransienteista johtuva virhe
• Palautesilmukat käyttäytyvät väärin
• Muistinhallintalaitteiston virheellinen tai väärä ohjaus
• Dataväylän kilpailuongelma
• Kentällä ladattavien ohjelmistojen yhteensopivuuden ja oikeellisuuden tarkistamismekanismin virheellinen toiminta

Hardware Software Integration käsittelee korkean tason vaatimusten varmentamista. Kaikki tämän tason testit suoritetaan kohdelaitteistolla.

• Mustan laatikon testaus on ensisijainen testausmenetelmä, jota käytetään tällä testaustasolla.
• Määritellä testitapaukset vain korkean tason vaatimuksista
• Testi on suoritettava tuotannon vakiolaitteistolla (kohteessa)

Asioita, jotka on otettava huomioon suunniteltaessa testitapauksia HW/SW-integraatiolle

• Ohjelmisto hankkii kaikki tiedot oikein
• Skaalaus ja tiedon valikoima odotetusti laitteistosta ohjelmistoon
• Oikea tietojen tulostus ohjelmistosta laitteistoon
• Tiedot määritysten sisällä (normaali alue)
• Tiedot määritysten ulkopuolella (epänormaali alue)
• Rajatiedot
• Keskeyttää käsittelyn
• Ajoitus
• Oikea muistin käyttö (osoitteet, päällekkäisyydet jne.)
• Tilanvaihdokset

Huomautus: Keskeytystestausta varten kaikki keskeytykset tarkistetaan itsenäisesti alkuperäisestä pyynnöstä täyden huollon ja valmistumisen jälkeen. Testitapaukset suunnitellaan erityisesti keskeytyksiä testaamaan riittävästi.

Ohjelmistosta ohjelmistointegraatiotestaukseen

Kyseessä on isäntä-/kohdetietokoneympäristössä toimivan tietokoneohjelmistokomponentin testaus samalla simuloiden koko järjestelmää [muita CSC:itä] ja sen korkean tason toiminnallisuutta.

Se keskittyy CSC:n käyttäytymiseen simuloidussa isäntä/kohde-ympäristössä. Ohjelmistointegraatiossa käytetty lähestymistapa voi olla inkrementaalinen lähestymistapa (ylhäältä alas, alhaalta ylös tai näiden yhdistelmä, jota kutsutaan myös voileipä- tai hybridilähestymistavaksi).

Integraatiotestauksen sisään- ja poistumiskriteerit

Kun lähestymistapa ja kaksi integraatiovarianttia on sovittu, jäljelle jää kysymys, milloin tiimi voi aloittaa ja milloin se voi lopettaa. Yleensä integraatiotestausta suoritettaessa käytetään ETVX-strategiaa (Entry Criteria, Task, Validation, and Exit Criteria).

Pääsyperusteet:

• Loppuunsaattaminen Yksikkötestaus

Tulot:

• Ohjelmistovaatimustiedot
• Ohjelmiston suunnitteluasiakirja
• Ohjelmiston vahvistussuunnitelma
• Ohjelmiston integrointiasiakirjat

Aktiviteetit:

• Korkean ja matalan tason vaatimusten perusteella luodaan testitapauksia ja -menettelyjä
• Yhdistä matalan tason moduuleita, jotka toteuttavat yhteisen toiminnallisuuden
• Kehitä testivaljaat
• Testaa rakennetta
• Kun testi on läpäissyt, koontiversio yhdistetään muihin koontiversioihin ja testataan, kunnes järjestelmä on integroitu kokonaisuutena.
• Suorita kaikki testit uudelleen kohdeprosessoripohjaisella alustalla ja hanki tulokset

Poistumisperusteet:

• Ohjelmistomoduulin integrointi kohdelaitteistoon on saatu päätökseen
• Ohjelmiston oikea suorituskyky määritettyjen vaatimusten mukaisesti

Lähdöt

• Integraatiotestiraportit
• Ohjelmistojen testaustapaukset ja -menettelyt [SVCP].

Yleisiä haasteita järjestelmäintegraatiotestauksessa

Vaikka lähestymistapa olisi järkevä ja lopetuskriteerit selkeät, integroidut ympäristöt luovat ongelmia, jotka eivät koskaan tule esiin yksikkötestauksen aikana. Niiden tunnistaminen varhain pitää aikataulun realistisena.

• Ympäristön epäsuhta: integroitu testiympäristössä harvoin heijastaa tuotantoa, joten ajoitus- ja konfiguraatiovirheet ilmenevät hyvin myöhään.
• Riippuvuusvalmius: Kolmannen osapuolen ja vanhat rajapinnat ovat usein keskeneräisiä, mikä pakottaa testaajat turvautumaan tynkiin ja simulaattoreihin paljon suunniteltua pidempään.
• Tietojen epäjohdonmukaisuus: Kaksi moduulia voi esittää samaa tietuetta eri tavalla, mikä aiheuttaa näkyvien virheiden sijaan hiljaisia ​​​​epäsuhtauksia.
• Vian omistajuus: kun epäonnistuminen koskee kahta tiimiä, perusteluanalyysi ja vianhallinnan hidastaa huomattavasti.
• Regressiokustannukset: jokainen uusi käyttöliittymä laajentaa regressiotestaus suite, joten manuaalinen uudelleensuorittaminen muuttuu nopeasti kestämättömäksi.

Useimmat näistä ovat aikatauluriskejä pikemminkin kuin teknisiä umpikuja. Rajapintojen valmiuspäivistä, simulaattorin laajuudesta ja vikaluokituksen omistajuudesta sopiminen ennen ensimmäisen koontiversion integrointia poistaa suurimman osan näistä riskeistä. Toimittajan omistamien rajapintojen osalta kirjaa myös sovittu viestimuoto ja eskalointiyhteystiedot, koska puuttuva omistaja viivästyttää korjausta kauemmin kuin vika vaatii.

Järjestelmäintegraatiotestauksen parhaat käytännöt

Toistettavissa oleva SIT-sykli on vähemmän riippuvainen työkaluista kuin rajapintojen, datan ja todisteiden kurinalaisuudesta. Alla olevat viisi käytäntöä sopivat yhtä lailla sekä pieneen sulautettuun testausympäristöön että suureen usean toimittajan ympäristöön, ja jokainen niistä vähentää uudelleentyön tarvetta myöhemmille testaustasoille.

1. Kartoita jokainen rajapinta ensin. Listaa jokainen tiedonvaihto, sen suunta, protokolla ja omistaja ennen yksittäisen testitapauksen kirjoittamista.
2. Priorisoi riskin mukaan. Tarkista rahaa, henkilöllisyyttä tai säänneltyjä tietoja kuljettavat rajapinnat ennen kosmeettisia rajapintoja.
3. Suunnittele realistinen testidata. Kattaa normaalit, reuna- ja epänormaalit alueet, jotta skaalaus- ja pyöristysvirheet tulevat esiin varhaisessa vaiheessa.
4. Automatisoi vakaat polut. Johtoliitäntä tarkistaa jatkuva integrointi putkilinja, joten jokainen koontiversio tarkistaa ne uudelleen.
5. Säilytä todisteet trackyvykäs. Linkitä jokainen tulos vaatimukseen linkin kautta trackyvykkyysmatriisi Joten poistumiskriteerit voidaan todistaa, ei väittää.

⚠ Vinkki: Jäädytä rajapinnan määritykset ennen integraation aloittamista. Myöhäinen viestimuodon muutos mitätöi testitapaukset rajapinnan molemmilla puolilla ja on yleisin yksittäinen syy SIT-uudelleentyöstämiseen.

UKK