Tässä osiossa aiomme ymmärtää erilaisia ohjelmistotestauksia, joita voidaan käyttää ohjelmistokehityksen elinkaaren aikana.
Kuten tiedämme, ohjelmistojen testaus on prosessi, jossa analysoidaan sovelluksen toimivuutta asiakkaan edellytysten mukaisesti.
Jos haluamme varmistaa, että ohjelmistomme on virheetön tai vakaa, meidän on suoritettava erilaisia ohjelmistotestauksia, koska testaus on ainoa menetelmä, joka tekee sovelluksestamme virheettömän.
Erilaiset ohjelmistotestaukset
Ohjelmistotestauksen luokittelu on osa monipuolista testaustoimintaa, mm testistrategia, testitulokset, määritelty testitavoite jne . Ja ohjelmistojen testaus on ohjelmiston suorittamista vikojen löytämiseksi.
Testaustyypin tarkoituksena on varmistaa AUT (Hakemus testattavana).
Testauksen aloittamiseksi meillä pitäisi olla a vaatimus, sovellusvalmis, tarvittavat resurssit saatavilla . Vastuullisuuden ylläpitämiseksi meidän tulisi osoittaa vastaava moduuli eri testausinsinööreille.
Ohjelmistojen testaus jakautuu pääasiassa kahteen osaan, jotka ovat seuraavat:
Mitä on manuaalinen testaus?
Minkä tahansa ohjelmiston tai sovelluksen testaaminen asiakkaan tarpeiden mukaan ilman automaatiotyökalua tunnetaan nimellä manuaalinen testaus .
Toisin sanoen voimme sanoa, että se on menettely todentaminen ja validointi . Manuaalista testausta käytetään tarkistamaan sovelluksen tai ohjelmiston käyttäytyminen vaatimusten määrittelyn vastaisesti.
mamta kulkarni
Emme vaadi tarkkoja tietoja mistään testaustyökalusta suorittaaksemme manuaalisia testitapauksia. Voimme helposti valmistella testiasiakirjan samalla kun suoritamme manuaalisen testauksen missä tahansa sovelluksessa.
Saat tarkkoja tietoja manuaalisesta testauksesta napsauttamalla seuraavaa linkkiä: https://www.javatpoint.com/manual-testing.
Manuaalisen testauksen luokitus
Ohjelmistotestauksessa manuaalinen testaus voidaan luokitella edelleen kolme erilaista testiä , jotka ovat seuraavat:
Katsotaanpa ne yksitellen, jotta ymmärrämme paremmin:
Valkoisen laatikon testaus
White-box-testauksessa kehittäjä tarkastaa jokaisen koodirivin ennen kuin luovuttaa sen testaustiimille tai asianomaisille testiinsinööreille.
Myöhemmin koodi on havaittavissa kehittäjille koko testauksen ajan; siksi tämä prosessi tunnetaan nimellä WBT (White Box Testing) .
Toisin sanoen voimme sanoa, että kehittäjä suorittaa täydellisen valkoisen laatikon testauksen tietylle ohjelmistolle ja lähettää tietyn sovelluksen testaustiimille.
White box -testauksen toteutuksen tarkoituksena on korostaa sisään- ja lähtövirtaa ohjelmiston yli ja parantaa sovelluksen turvallisuutta.
Valkoisen laatikon testaus tunnetaan myös nimellä avoimen laatikon testaus, lasilaatikon testaus, rakennetestaus, läpinäkyvän laatikon testaus ja läpinäkyvän laatikon testaus .
Saat perusteelliset tiedot valkoisen laatikon testaamisesta alla olevasta linkistä: https://www.javatpoint.com/white-box-testing.
Mustan laatikon testaus
Toinen manuaalisen testauksen tyyppi on mustan laatikon testaus . Tässä testauksessa testiinsinööri analysoi ohjelmiston vaatimusten perusteella, tunnistaa viat tai bugit ja lähettää sen takaisin kehitystiimille.
Sitten kehittäjät korjaavat nämä viat, tekevät yhden White box -testauskierroksen ja lähettävät sen testaustiimille.
Tässä virheiden korjaaminen tarkoittaa, että vika on korjattu ja tietty ominaisuus toimii annetun vaatimuksen mukaisesti.
Black Box -testauksen toteutuksen päätavoitteena on täsmentää liiketoiminnan tarpeet tai asiakkaan vaatimukset.
Toisin sanoen voidaan sanoa, että black box -testaus on prosessi, jossa tarkistetaan sovelluksen toimivuus asiakkaan vaatimusten mukaisesti. Lähdekoodi ei näy tässä testauksessa; siksi se tunnetaan nimellä mustan laatikon testaus .
Lisätietoja Black Box -testauksesta saat alla olevasta linkistä: https://www.javatpoint.com/black-box-testing.
Black Box -testauksen tyypit
Mustan laatikon testaus luokitellaan edelleen kahteen osaan, joita käsitellään alla:
Toiminnallinen testaus
Testausinsinööri tarkistaa kaikki komponentit järjestelmällisesti vaatimusten mukaisesti toiminnallinen testaus . Toiminnallinen testaus tunnetaan myös nimellä Komponenttien testaus .
Toiminnallisessa testauksessa kaikki komponentit testataan antamalla arvo, määrittelemällä tulos ja validoimalla todellinen tulos odotetulla arvolla.
Toiminnallinen testaus on osa black-box-testausta, koska se korostaa sovellusvaatimusta varsinaisen koodin sijaan. Testausinsinöörin on testattava vain ohjelmaa järjestelmän sijaan.
Yksityiskohtaiset tiedot toiminnallisesta testauksesta löydät alla olevasta linkistä: https://www.javatpoint.com/functional-testing .
Toiminnallisen testauksen tyypit
Kuten toinenkin testaustyyppi on jaettu useisiin osiin, myös toiminnallinen testaus luokitellaan eri luokkiin.
Monipuolinen toiminnallisen testauksen tyypit sisältää seuraavat:
Ymmärretään nyt ne yksitellen:
1. Yksikkötestaus
Yksikkötestaus on toiminnallisen testauksen ensimmäinen taso minkä tahansa ohjelmiston testaamiseksi. Tässä testaaja testaa sovelluksen moduulia itsenäisesti tai testaa kaikkia moduulin toimintoja kutsutaan yksikkötestaus .
Yksikkötestauksen suorittamisen ensisijaisena tavoitteena on varmistaa yksikön komponenttien suorituskyky. Tässä yksikkö määritellään yhdeksi testattavaksi ohjelmiston tai sovelluksen funktioksi. Ja se varmistetaan koko määritetyn sovelluksen kehitysvaiheen ajan.
Napsauta alla olevaa linkkiä saadaksesi täydelliset tiedot yksikkötestauksesta: https://www.javatpoint.com/unit-testing.
2. Integraatiotestaus
Kun olemme toteuttaneet yksikkötestauksen onnistuneesti, siirrymme integraatiotestaukseen. Se on toiminnallisen testauksen toinen taso, jossa testaamme tietovirtaa riippuvaisten moduulien välillä tai kahden ominaisuuden välistä rajapintaa kutsutaan ns. integraatiotestaus .
Integrointitestauksen suorittamisen tarkoituksena on testata käskyn tarkkuus kunkin moduulin välillä.
Integraatiotestauksen tyypit
Integraatiotestaus on myös jaettu edelleen seuraaviin osiin:
Inkrementaalinen integraatiotestaus
Aina kun moduulien välillä on selkeä suhde, ryhdymme inkrementaaliseen integrointitestaukseen. Oletetaan, että otamme kaksi moduulia ja analysoimme niiden välistä tietovirtaa, toimivatko ne hyvin vai eivät.
Jos nämä moduulit toimivat hyvin, voimme lisätä vielä yhden moduulin ja testata uudelleen. Ja voimme jatkaa samaa prosessia saadaksemme parempia tuloksia.
Toisin sanoen voidaan sanoa, että moduulien asteittainen lisääminen ja moduulien välisen datavirran testaus tunnetaan nimellä Inkrementaalinen integraatiotestaus .
parseint java
Inkrementaalisen integraatiotestauksen tyypit
Inkrementaalinen integrointitestaus voidaan edelleen luokitella kahteen osaan, jotka ovat seuraavat:
Katsotaanpa lyhyt esittely tämän tyyppisistä integraatiotestauksista:
1. Ylhäältä alas inkrementaalinen integrointitestaus
Tässä lähestymistavassa lisäämme moduulit askel askeleelta tai asteittain ja testaamme niiden välistä tiedonkulkua. Meidän on varmistettava, että lisäämämme moduulit ovat aikaisempien lapsi .
2. Alhaalta ylöspäin suuntautuva inkrementaalinen integrointitestaus
Alhaalta ylös -lähestymistavassa lisäämme moduulit asteittain ja tarkistamme moduulien välisen datavirran. Varmista myös, että lisäämämme moduuli on aikaisempien vanhempien .
Ei-inkrementaalinen integraatiotestaus / Big Bang -menetelmä
Aina kun tietovirta on monimutkaista ja erittäin vaikeaa luokitella vanhemmaksi ja lapseksi, valitsemme ei-inkrementaalisen integroinnin. Ei-inkrementaalinen menetelmä tunnetaan myös nimellä Big Bang -menetelmä .
Saat täydelliset tiedot integraatiotestauksesta ja sen tyypistä seuraavasta linkistä: https://www.javatpoint.com/integration-testing .
3. Järjestelmän testaus
Aina kun olemme tehneet yksikkö- ja integrointitestauksen, voimme jatkaa järjestelmätestausta.
Järjestelmätestauksessa testiympäristö on rinnakkainen tuotantoympäristön kanssa. Se tunnetaan myös nimellä päittäin testaus.
Tämän tyyppisessä testauksessa käymme läpi ohjelmiston jokaisen attribuutin ja testaamme, toimiiko loppuominaisuus liiketoimintavaatimusten mukaisesti. Ja analysoi ohjelmistotuote kokonaisena järjestelmänä.
Napsauta alla olevaa linkkiä saadaksesi täydelliset tiedot järjestelmätestauksesta: https://www.javatpoint.com/system-testing .
Toimimaton testaus
Black-box-testauksen seuraava osa on ei-toiminnallinen testaus . Se tarjoaa yksityiskohtaista tietoa ohjelmistotuotteen suorituskyvystä ja käytetyistä teknologioista.
Ei-toiminnallinen testaus auttaa meitä minimoimaan ohjelmiston tuotantoriskin ja siihen liittyvät kustannukset.
Ei-toiminnallinen testaus on yhdistelmä suorituskyky, kuormitus, stressi, käytettävyys ja yhteensopivuuden testaus .
Lisätietoja ei-toiminnallisesta testauksesta on seuraavassa linkissä: https://www.javatpoint.com/non-functional-testing .
Ei-toiminnallisen testauksen tyypit
Ei-toiminnallinen testaus luokitellaan testauksen eri osiin, joista aiomme keskustella lisää:
1. Suorituskykytestaus
Suorituskykytestauksessa testiinsinööri testaa sovelluksen toimintaa kuormittamalla.
Tämän tyyppisessä ei-toiminnallisessa testauksessa testiinsinööri keskittyy vain useisiin näkökohtiin, kuten Vasteaika, kuormitus, skaalautuvuus ja vakaus ohjelmistosta tai sovelluksesta.
Suorituskykytestauksen luokitus
Suorituskykytestaus sisältää erilaisia testaustyyppejä, jotka ovat seuraavat:
Suorituskykytestauksen aikana kuormitamme tiettyä sovellusta tarkistaaksemme sovelluksen suorituskyvyn, ns. kuormitustestaus . Tässä kuorma voi olla pienempi tai yhtä suuri kuin haluttu kuorma.
Se auttaa meitä havaitsemaan ohjelmiston suurimman käyttömäärän ja pullonkaulat.
Saat täydelliset kuormitustestaukseen liittyvät tiedot alla olevasta linkistä:
https://www.javatpoint.com/load-testing.
Sen avulla analysoidaan ohjelmiston käyttäjäystävällisyyttä ja kestävyyttä yleisten toiminnallisten rajojen yli.
Stressitestausta käytetään ensisijaisesti kriittisille ohjelmistoille, mutta sitä voidaan käyttää myös kaikentyyppisissä ohjelmistosovelluksissa.
Alla olevasta linkistä löydät perusteelliset tiedot stressitestauksesta: https://www.javatpoint.com/stress-testing.
Analyysissa sovelluksen suorituskykyä lisäämällä tai vähentämällä kuormitusta tietyissä tasapainoissa tunnetaan nimellä skaalautuvuuden testaus .
Skaalautuvuustestauksessa voimme myös tarkistaa järjestelmän, prosessien tai tietokannan kyky kasvavan tarpeen tyydyttämiseksi. Ja tässä, Testitapaukset ne suunnitellaan ja toteutetaan tehokkaasti.
Napsauta seuraavaa linkkiä saadaksesi yksityiskohtaiset tiedot skaalautuvuustestauksesta:
https://www.javatpoint.com/scalability-testing.
Vakavuustestaus on menettely, jossa arvioimme sovelluksen suorituskykyä kuormittamalla tarkan ajan.
Se tarkastaa pääasiassa sovelluksen pysyvyysongelmia ja kehitetyn tuotteen tehokkuutta. Tämän tyyppisessä testauksessa löydämme järjestelmän vian nopeasti myös stressaavassa tilanteessa.
Saat yksityiskohtaisia tietoja vakavuustestauksesta alla olevasta linkistä:
https://www.javatpoint.com/stability-testing.
2. Käytettävyystestaus
Toinen tyyppi ei-toiminnallinen testaus On käytettävyystestaus . Käytettävyystestauksessa analysoimme sovelluksen käyttäjäystävällisyyttä ja havaitsemme ohjelmiston käyttöliittymän virheet.
Tässä termi käyttäjäystävällisyys määrittelee seuraavat sovelluksen osat:
- Sovelluksen tulee olla helposti ymmärrettävä, mikä tarkoittaa, että kaikkien ominaisuuksien tulee olla loppukäyttäjien nähtävissä.
- Sovelluksen ulkoasun ja tuntuman tulee olla hyvä, mikä tarkoittaa, että sovelluksen tulee olla miellyttävän näköinen ja antaa loppukäyttäjälle tuntuman sen käytöstä.
Lisätietoja käytettävyystestauksesta löytyy seuraavasta linkistä:
https://www.javatpoint.com/usability-testing.
3. Yhteensopivuuden testaus
Yhteensopivuustestauksessa tarkistamme sovelluksen toimivuuden tietyissä laitteisto- ja ohjelmistoympäristöissä. Kun sovellus on toiminnallisesti vakaa, lähdemme eteenpäin yhteensopivuustestaus .
Tässä, ohjelmisto tarkoittaa, että voimme testata sovellusta eri käyttöjärjestelmissä ja muissa selaimissa, ja laitteisto tarkoittaa, että voimme testata sovellusta erikokoisilla.
Saat perusteelliset tiedot yhteensopivuustestauksesta alla olevasta linkistä:
https://www.javatpoint.com/compatibility-testing .
Harmaan laatikon testaus
Toinen osa manuaalinen testaus On Harmaan laatikon testaus . Se on a mustan laatikon ja valkoisen laatikon testauksen yhteistyö .
Koska harmaa laatikko -testaus sisältää pääsyn sisäiseen koodaukseen testitapausten suunnittelua varten. Grey box -testauksen suorittaa henkilö, joka osaa koodauksen ja testauksen.
Toisin sanoen voimme sanoa, että jos yhden hengen joukkue teki molemmat valkoisen ja mustan laatikon testaus , se on harkittu Harmaan laatikon testaus .
Saat tarkemmat tiedot Grey box -testauksesta alla olevasta linkistä:
https://www.javatpoint.com/grey-box-testing.
Automaatiotestaus
Merkittävin osa ohjelmistotestausta on automaatiotestaus. Se käyttää erityisiä työkaluja manuaalisen suunnittelun testitapausten automatisointiin ilman ihmisen puuttumista.
kohdista css-kuva
Automaatiotestaus on paras tapa parantaa ohjelmistotestauksen tehokkuutta, tuottavuutta ja kattavuutta.
Sitä käytetään manuaalisesti, nopeasti ja toistuvasti suoritettujen testiskenaarioiden uudelleen suorittamiseen.
Toisin sanoen voimme sanoa, että aina kun testaamme sovellusta käyttämällä joitain työkaluja, tunnetaan nimellä automaatiotestaus .
Automaatiotestaukseen lähdemme, kun sovellukseen tai ohjelmistoon menee useita julkaisuja tai useita regressiojaksoja. Emme voi kirjoittaa testiskriptiä tai suorittaa automaatiotestausta ymmärtämättä ohjelmointikieltä.
Saat lisätietoja automaatiotestauksesta alla olevasta linkistä:
https://www.javatpoint.com/automation-testing.
Joitakin muita ohjelmistotestaustyyppejä
Ohjelmistotestauksessa meillä on myös muita testaustyyppejä, jotka eivät kuulu mihinkään edellä mainittuun testaukseen, mutta ne ovat pakollisia mitä tahansa ohjelmistoa tai sovellusta testattaessa.
Ymmärretään nämä testityypit yksitellen:
Sisään savutestaus , testaamme sovelluksen perus- ja kriittisiä ominaisuuksia ennen kuin teemme yhden syvällisen ja tiukan testauksen.
Tai ennen kaikkien mahdollisten positiivisten ja negatiivisten arvojen tarkistamista tunnetaan nimellä savutestaus . Sovelluksen ydin- ja päätoimintojen työnkulun analysointi on savutestauksen suorittamisen päätavoite.
Lisätietoja savutestauksesta löytyy seuraavasta linkistä:
https://www.javatpoint.com/smoke-testing.
Terveyden testaus
Sitä käytetään varmistamaan, että kaikki virheet on korjattu eikä näiden muutosten vuoksi esiinny mitään lisäongelmia. Sanity-testaus on käsikirjoittamaton, mikä tarkoittaa, että emme voi dokumentoida sitä. Se tarkistaa äskettäin lisättyjen ominaisuuksien ja komponenttien oikeellisuuden.
Saat tarkemmat tiedot tervejärkisyystestauksesta alla olevasta linkistä:
https://www.javatpoint.com/sanity-testing.
Regressiotestaus
Regressiotestaus on yleisimmin käytetty ohjelmistotestaustyyppi. Tässä termi regressio tarkoittaa, että meidän on testattava uudelleen ne osat sovelluksesta, johon se ei vaikuta.
Regressiotestaus on sopivin testaus automaatiotyökaluille. Projektin tyypin ja resurssien saatavuuden mukaan regressiotestaus voi olla samanlainen kuin Uudelleentestaus .
Aina kun kehittäjät korjaavat vian ja testaavat sitten muita sovellusten ominaisuuksia, joita voidaan simuloida virheenkorjauksen vuoksi, kutsutaan nimellä regressiotestaus .
Toisin sanoen voimme sanoa, että aina kun johonkin projektiin tulee uusi julkaisu, voimme suorittaa regressiotestauksen, ja uuden ominaisuuden vuoksi voi vaikuttaa aiempien julkaisujen vanhoihin ominaisuuksiin.
Saadaksesi perusteelliset tiedot regressiotestauksesta, katso alla olevaa linkkiä:
https://www.javatpoint.com/regression-testing .
Käyttäjän hyväksyntätestaus
Käyttäjähyväksyntätestauksen (UAT) suorittaa yksittäinen tiimi, joka tunnetaan nimellä toimialueen asiantuntija/asiakas tai asiakas. Ja hakemuksen tuntemista ennen lopullisen tuotteen hyväksymistä kutsutaan nimellä käyttäjän hyväksyntätestaus .
Käyttäjien hyväksyntätestauksessa analysoimme liiketoimintaskenaarioita ja reaaliaikaisia skenaarioita erillisessä ympäristössä, jota kutsutaan nimellä UAT-ympäristö . Tässä testauksessa testaamme sovellusta ennen UAI:ta asiakkaan hyväksyntää varten.
Saat lisätietoja käyttäjien hyväksyntätestauksesta napsauttamalla alla olevaa linkkiä:
https://www.javatpoint.com/acceptance-testing.
Tutkiva testaus
Aina kun vaatimus puuttuu, vaaditaan varhainen iterointi, ja testaustiimillä on kokeneita testaajia, kun meillä on kriittinen sovellus. Uusi testausinsinööri tuli tiimiin, sitten lähdemme mukaan tutkiva testaus .
Tutkivan testauksen suorittamiseksi käymme ensin sovelluksen läpi kaikilla mahdollisilla tavoilla, teemme testidokumentin, ymmärrämme sovelluksen kulkua ja testaamme sitten sovellusta.
Napsauta seuraavaa linkkiä saadaksesi täydelliset tiedot kokeellisesta testauksesta:
https://www.javatpoint.com/exploratory-testing.
Adhoc-testaus
Sovelluksen testaus satunnaisesti heti, kun koontiversio on tarkistetussa järjestyksessä, tunnetaan nimellä Adhoc-testaus .
Sitä kutsutaan myös Apinatestaus ja Gorilla-testaus . Adhoc-testauksessa tarkistamme sovelluksen asiakkaan vaatimusten vastaisesti; siksi se tunnetaan myös nimellä negatiivinen testi .
Kun loppukäyttäjä käyttää sovellusta satunnaisesti, ja hän voi havaita virheen. Silti erikoistunut testausinsinööri käyttää ohjelmistoa perusteellisesti, joten hän ei välttämättä tunnista vastaavaa havaitsemista.
Katso tarkemmat tiedot Adhoc-testauksesta:
gimp vienti jpg-muodossa
https://www.javatpoint.com/adhoc-testing.
Turvallisuustestaus
Se on olennainen osa ohjelmistotestausta, jota käytetään ohjelmistosovelluksen heikkouksien, riskien tai uhkien määrittämiseen.
Turvatestauksen suorittaminen auttaa meitä välttämään ulkopuolisten ilkeän hyökkäyksen ja varmistamaan ohjelmistosovellustemme turvallisuuden.
Toisin sanoen voidaan sanoa, että tietoturvatestauksella pääosin määritellään, että tiedot ovat turvallisia ja kestävät ohjelmiston työprosessin.
Saat täydelliset tiedot tietoturvatestauksesta alla olevasta linkistä: https://www.javatpoint.com/security-testing.
Globalisaation testaus
Toinen ohjelmistotestaustyyppi on Globalisaation testaus. Globalisaatiotestauksella tarkistetaan, onko kehitetty ohjelmisto useita kieliä vai ei. Tässä sanat globalisaatio tarkoittaa sovelluksen tai ohjelmiston valaisemista eri kielille.
Globalisaatiotestauksella varmistetaan, että sovellus tukee useita kieliä ja useita ominaisuuksia.
Nykyisissä skenaarioissa voimme nähdä parannusta useissa teknologioissa, kun sovelluksia valmistetaan maailmanlaajuisesti.
Seuraavasta linkistä saat täydelliset tiedot globalisaatiotestaukseen liittyen:
https://www.javatpoint.com/globalization-testing.
Johtopäätös
Opetusohjelmassa olemme keskustelleet erilaisista ohjelmistotestauksista. Mutta silti on luettelo yli 100 testauskategoriasta. Jokaisen tyyppistä testausta ei kuitenkaan käytetä kaikentyyppisissä projekteissa.
Olemme keskustelleet yleisimmin käytetyistä ohjelmistotestauksen tyypeistä, kuten black-box -testaus, valkoisen laatikon testaus, toiminnallinen testaus, ei-toiminnallinen testaus, regressiotestaus, Adhoc-testaus jne. .
Lisäksi on olemassa vaihtoehtoisia luokituksia tai prosesseja, joita käytetään erilaisissa organisaatioissa, mutta yleinen käsite on samanlainen kaikkialla.
Nämä testaustyypit, prosessit ja suoritustavat muuttuvat jatkuvasti, kun projekti, vaatimukset ja laajuus muuttuvat.