mikään ohjelmisto ei voi koskaan olla täysin täydellinen. Mutta onko se lupa luoda roskia? Puuttuva ainesosa on haluttomuus kvantifioida laatua. Laadun parantamiseksi on erittäin tärkeää varmistaa ohjelmistosovellusten tehokas suorituskyky. Ohjelmiston testaus on tarpeen sen varmistamiseksi, että sovellus toimii ilman vikoja. Tässä Ohjelmistojen testaus opetusohjelma, kerron sinulle kaiken mitä sinun tarvitsee tietää testaus näkökohtia. Jatkoa edelliseen blogiin siitä, mikä on Ohjelmistojen testaus, täällä aion sukeltaa syvemmälle ja kattaa alla mainitut aiheet.
- Johdatus ohjelmistojen testaukseen
- ohjelmistojen testauksen perusteet
- ohjelmistokehityksen elinkaari
- ohjelmistojen testausmenetelmät
- ohjelmistojen testausmenetelmät
- ohjelmistojen testausmenetelmät
- ohjelmistojen testausmenetelmät
- ohjelmistojen testausmenetelmät
- ohjelmistojen testausmenetelmät
- ohjelmistojen Testausasiakirjat Artefaktit
- vian elinkaari
- manuaalisen testauksen haasteet
- Automaatiotestauksen vs manuaalisen testauksen haasteet
voit myös käydä läpi ohjelmistotestauksen opetusohjelman tallentamisen, jossa Ohjelmistotestauskoulutuksen Asiantuntijat ovat selittäneet käsitteet syvällisesti.
Software Testing Tutorial for Beginners / Manual & Automation Testing
videolla puhutaan erilaisista testaustavoista eli manuaalisesta testauksesta ja automaation testausmenetelmistä.
Johdatus ohjelmistotestaukseen
nykypäivän tekniikan maailma on täysin koneiden hallitsema, ja niiden käyttäytymistä ohjaa sitä virtaava ohjelmisto. Ohjelmistojen testaus tarjoaa kustannustehokkaan ratkaisun kaikkiin huoliimme. Mikä on Ohjelmistojen testaus? Ohjelmistojen testaus on prosessi, jossa arvioidaan ohjelmistosovelluksen toimivuutta mahdollisten ohjelmistovirheiden löytämiseksi. Se tarkistaa, täyttääkö kehitetty ohjelmisto asetetut vaatimukset, ja tunnistaa, onko ohjelmistossa puutteita laatutuotteen saavuttamiseksi. Se on pohjimmiltaan suorittaa järjestelmän tunnistaa aukkoja, virheitä, tai puuttuvat vaatimukset vastoin todellisia vaatimuksia.
It is also indicated as the process of verifying and validizing a software product. Se tarkistaa, onko ohjelmisto tuote:
- täyttää sen suunnittelua ja kehittämistä ohjanneet liiketaloudelliset ja tekniset vaatimukset
- vaatimuksen mukaiset työt
- voidaan toteuttaa samoin ominaisuuksin
nyt, siirrytään pidemmälle Ohjelmistojen testaus opetusohjelma artikkeli ja saada joitakin oivalluksia perusasiat Ohjelmistojen testaus.
ohjelmistotestauksen perusteet
ensin kerron, mikä on ohjelmistokehityksen elinkaari?
Software Development Life Cycle
(SDLC) lyhennettynä Software Development Life Cycle on prosessi, jota ohjelmistoteollisuus käyttää korkealaatuisten ohjelmistojen suunnitteluun, kehittämiseen ja testaamiseen. Sen tavoitteena on tuottaa korkealaatuisia ohjelmistoja, jotka täyttävät tai ylittävät asiakkaiden odotukset, valmistuvat ajan ja kustannusarvioiden puitteissa. Alla oleva kaavio kuvaa SDLC: n eri vaiheita.
Fig: Software Development Life Cycle-Software Testing Tutorial
Requirement Phase
Requirement gathering and analysis on ohjelmistokehityksen elinkaaren tärkein vaihe. Business analyst kerää vaatimuksen asiakkaalta/asiakkaalta kohti asiakkaiden liiketoiminnan tarpeisiin ja dokumentoi vaatimukset liiketoiminnan vaatimus erittely (asiakirjan nimi vaihtelee riippuu organisaatiosta).
Analysointivaihe
kun vaatimukset on kerätty ja analysoitu, seuraava vaihe on määritellä ja dokumentoida tuotevaatimukset ja saada ne asiakkaan hyväksymiksi. Tämä kirjataan SRS (Software Requirement Specification) – dokumentin kautta. Se koostuu kaikista tuotevaatimuksista, jotka on suunniteltava ja kehitettävä projektin elinkaaren aikana
suunnitteluvaihe
tässä vaiheessa on kaksi vaihetta:
- HLD-korkean tason suunnittelu – Se antaa kehitettävän ohjelmistotuotteen arkkitehtuurin ja sen tekevät arkkitehdit ja senior developers
- LLD-matalan tason suunnittelu – sen suorittavat senior developers. Tässä, se antaa sinulle oivalluksia siitä, miten jokainen ominaisuus tuotteen pitäisi toimia ja miten jokainen komponentti pitäisi toimia.
tämän vaiheen tulos on korkean ja matalan tason dokumentti, joka toimii syötteenä seuraavaan vaiheeseen.
kehitysvaihe
kaikentasoiset Kehittäjät (seniorit, juniorit, fuksit) ovat mukana tässä vaiheessa. Tämä on vaihe, jossa alkaa rakentaa koodia ohjelmiston.
testausvaihe
kun ohjelmisto on valmis, se lähetetään testausosastolle, jossa se testataan perusteellisesti erilaisten vikojen varalta. Ohjelmiston testaus suoritetaan joko manuaalisesti tai automatisoituja testausvälineitä käyttäen ja varmistetaan, että jokainen ohjelmiston osa toimii hyvin. Kun ohjelmisto on virheetön, se menee seuraavaan vaiheeseen, joka on toteutus.
käyttöönotto & ylläpitovaihe
kun tuote on virheetön, se toimitetaan/otetaan asiakkaan käyttöön. Käyttöönoton tekevät käyttöönoton / käyttöönoton insinöörit. Kun asiakkaat alkavat käyttää kehitettyä järjestelmää, todelliset ongelmat tulevat esiin ja ne on ratkaistava aika ajoin. Asiakkaan havaitsemien ongelmien havaitseminen ja ratkaiseminen tulee ylläpitovaiheessa.
kyse oli ohjelmistokehityksen elinkaaresta. Jos haluat tietää eri vaiheissa mukana ohjelmistojen testaus prosessi, voit lukea tämän blogin Ohjelmistojen testaus elinkaaren. Ymmärrettyämme tämän, siirrytään eteenpäin tällä ohjelmistotestausopilla ja katsotaan, mikä on v & V-malli.
V-malli on nykyään yksi laajimmin käytetyistä ohjelmistokehitysprosesseista. V-mallin käyttöönotto on itse asiassa todistanut testauksen toteuttamisen heti vaatimusvaiheesta lähtien. Sitä kutsutaan myös nimellä Verification and Validation model
mitä on verifiointi ja validointi Ohjelmistotestauksessa?
verifiointi: verifiointi on staattinen analyysitekniikka. Täällä testaus tehdään ilman koodin suorittamista. Esimerkkejä ovat-arvostelut, tarkastus, ja kävellä läpi.
validointi: validointi on dynaamisen analyysin prosessi, jossa suoritamme testauksen suorittamalla koodin. Esimerkkejä ovat toiminnalliset ja ei-toiminnalliset testausmenetelmät.
V-mallissa kehitys-ja QA-toimet tehdään samanaikaisesti. Tässä testaus alkaa heti vaatimusvaiheesta. Todentamis-ja vahvistamistoimet tapahtuvat samanaikaisesti. Katsotaanpa alla olevaa kuvaa ymmärtääksemme V-mallin
tyypillisessä kehitysprosessissa vasemmalla puolella näkyy kehitystoiminta ja oikealla puolella testaus. Ei pitäisi olla väärin, jos sanon, että kehitysvaiheessa tehdään sekä todentamista että vahvistamista varsinaisten kehitystoimien ohella.
LHS
kuten aiemmin mainittiin, vasemmanpuoleinen toiminta on kehittämistoimintaa. Normaalisti meistä tuntuu, mitä testausta voimme tehdä kehitysvaiheessa? Mutta tämä on tämän mallin ydin, joka osoittaa, että testausta voidaan tehdä myös kaikissa kehitysvaiheissa.
RHS
testaus tai Validointivaihe suoritetaan mallin oikealla puolella.
koska olet saanut tästä oivalluksia, siirrytäänpä eteenpäin tämän ohjelmiston testausoppaan avulla ja katsotaan, mitkä ovat ne eri menetelmät, joilla ohjelmistoa voidaan testata.
ohjelmistojen testausmenetelmät
ohjelmistojen testausmenetelmiä on kolme ja ne ovat seuraavat:
- Black Box-testaus
- White Box-testaus
- Grey Box-testaus
Black Box-testaus: kyseessä on ohjelmistotestausmenetelmä, jossa testattavan kohteen sisäinen rakenne/ suunnittelu/ toteutus ei ole testaajan tiedossa.
White Box-testaus: kyseessä on ohjelmistotestausmenetelmä, jossa testattavan kohteen sisäinen rakenne/ suunnittelu/ toteutus on testaajan tiedossa.
Grey Box-testaus: kyseessä on testausmenetelmä, jossa on vain vähän tietoa järjestelmän sisäisestä toimivuudesta.
toivon, että ymmärsitte Keskeiset vihjeet eri ohjelmistotestausmenetelmistä. Nyt, siirrytään pidemmälle tässä Ohjelmistojen testaus opetusohjelma artikkeli ja ymmärtää Ohjelmistojen testaus tasoilla.
Ohjelmistotestaustasot
A-taso ohjelmistotestauksessa on prosessi, jossa ohjelmiston/järjestelmän jokaista yksikköä tai osaa testataan. On olemassa erilaisia testaustasoja, jotka auttavat tarkistamaan käyttäytymistä ja suorituskykyä ohjelmistojen testausta varten. Nämä testitasot on suunniteltu tunnistamaan puuttuvat alueet ja sovittamaan yhteen elinkaaritilojen kehitys. Ohjelmistokehityksen elinkaarimallissa on tyypillisiä vaiheita, kuten vaatimusten kerääminen, analysointi, suunnittelu, koodaus tai toteutus, testaus ja käyttöönotto.
kaikki nämä vaiheet käyvät läpi ohjelmistotestaustasojen prosessin. Testitasoja on pääasiassa neljä ja ne ovat:
- yksikkötestaus
- Integraatiotestaus
- Järjestelmätestaus
- Hyväksymistestaus
periaatteessa se alkaa Yksikkötestausvaiheella ja päättyy Hyväksymistestaukseen.
tämän ohjelmistotestauksen opetusohjelman seuraavassa osassa sukellan syvemmälle seuraavaan aiheeseen ja selitän, mitkä ovat erilaiset dokumentaatioesineet ohjelmistotestauksessa.
Software Testing Documentation artefacts
testitapausten dokumentointi auttaa sinua arvioimaan tarvittavan testaustyön sekä testauksen kattavuuden ja seuranta-ja jäljitysvaatimuksen. Joitakin yleisesti sovellettuja ohjelmistotestaukseen liittyviä dokumentaatioesineitä ovat:
- Testisuunnitelma
- Testiskenaario
- Testiskenaario
- Jäljitettävyysmatriisi
keskustellaan jokaisesta niistä lyhyesti.
- Testisuunnitelma: siinä on yleiskaava, joka toteutetaan sovelluksen testausta varten.
- Testiskenaario: Testiskenaario voidaan katsoa yhden rivin lausekkeeksi, jossa ilmoitetaan alue, jolla hakemustasi kokeillaan. Tämä artefakti on tarpeen varmistaa yleinen menettely testattu alusta loppuun.
- testitapaus: testitapaus on vain joukko olosuhteita tai muuttujia, joissa testaaja määrittää, täyttääkö testattava järjestelmä vaatimukset tai toimiiko se oikein. Alla mainitut testitapaukset tarkistetaan testauksen aikana.
- funktionaaliset testitapaukset
- negatiiviset virhetestitapaukset
- loogiset testitapaukset
- fyysiset testitapaukset
- UI – testitapaukset
- Jäljitettävyysmatriisi: se tunnetaan myös nimellä Requirement Traceability Matrix (RTM). Se sisältää taulukon, joka luonnostelee vaatimukset, kun tuotteesi SDLC-mallia luodaan. Näitä dokumentoivia artefakteja voidaan soveltaa eteenpäin jäljittämiseen, joka on tarkoitus siirtää suunnittelusta koodaukseen, tai ne voidaan toteuttaa myös taaksepäin jäljittämiseen, joka on etujäljityksen kääntöpuoli.
tästä päästään ohjelmistojen Testausdokumenttien artefaktien loppuun. Nyt, siirrytään pidemmälle tässä Ohjelmistojen testaus opetusohjelma artikkeli ja oppia, mikä on vika hallinta?
mikä on vikojen hallintaprosessi?
vikojen hallinta on vikojen havaitsemista ja korjaamista. Koska bugit ovat osa ohjelmistoteollisuutta, niitä esiintyy jatkuvasti ohjelmistokehitysprosessissa. Tiimin jäsenten on kirjoitettava suuria koodinpätkiä joka päivä, eivätkä he yleensä ehdi miettiä, miten ötököitä voisi välttää. Siksi jokainen ohjelmistokehitysprojekti vaatii prosessin, joka auttaa havaitsemaan viat ja korjaamaan ne.
Vianhallintaprosessi suoritetaan tuotetestausvaiheessa. Tätä tajuamatta olisi vaikea ymmärtää vianhallinnan luonnetta.. Yleensä kehittäjät testaavat tuotteensa itse. Myös, on myös eräänlainen testaus, joka perustuu käyttäjän osallistumista. Loppukäyttäjille tarjotaan usein mahdollisuus raportoida havaitsemistaan vioista. Tämä ei kuitenkaan ole paras tapa testata, koska käyttäjät eivät välttämättä pysty löytämään kaikkia vikoja.
vianhallintaprosessi sisältää yleensä neljä vaihetta.
- ensimmäinen vaihe on vian havaitsemisen vaihe
- toinen vaihe on omistettu vikailmoitusten laatimiselle
- kolmas vaihe on vian korjaaminen.
- viimeisessä vaiheessa luodaan vikaluettelo
nyt mennään pidemmälle ohjelmistojen testausoppiartikkelissa ja ymmärretään vian tunnistusprosessi vian elinkaaren avulla.
vian elinkaari
vian elinkaari on prosessi, jossa vika käy läpi eri vaiheita koko elinkaarensa ajan. Se alkaa, kun vika löytyy ja päättyy, kun vika on suljettu, varmistettuaan, että se ei toistu. Vian elinkaari liittyy testauksen aikana löydettyyn vikaan.
vian tai vian elinkaari sisältää alla olevan kuvan mukaiset vaiheet:
- Uusi: Tässä vaiheessa, jos vika on kirjautunut ja lähetetty ensimmäistä kertaa, sen tila annetaan uutena.
- annettu: kun testaaja on lähettänyt vian, testaajan johto hyväksyy vian aitouden ja hän antaa vian vastaavalle kehittäjälle ja kehittäjäryhmälle. Se on määrätty osavaltio.
- Open: tässä tilassa kehittäjä on aloittanut vian korjauksen analysoinnin ja työstämisen.
- Fixed: koska kehittäjä tekee tarvittavat koodimuutokset ja tarkistaa muutokset, hän voi tehdä vian tilan ”Fixed” ja vika siirtyy testiryhmälle.
- testi:tässä vaiheessa testaaja Testaa kehittäjän hänelle takaisin antaman muuttuneen koodin tarkistaakseen, onko vika korjattu vai ei.
- todennettu: tässä testaaja Testaa vian uudelleen sen jälkeen, kun kehittäjä on korjannut sen. Jos ohjelmistossa ei ole vikaa, hän hyväksyy vian korjaamisen ja muuttaa tilan ”verifiediksi”.
- Reopen: mikäli vika on edelleen olemassa senkin jälkeen, kun kehittäjä on korjannut vian, testaaja vaihtaa tilan muotoon ”reopen”. Tässä tilassa vika käy läpi elinkaaren jälleen kerran.
- suljettu: heti kun vika on korjattu, testaaja Testaa sen. Mikäli testaaja kokee, että vikaa ei enää ole ohjelmistossa, hän muuttaa vian tilan ”suljetuksi”. Se tarkoittaa, että vika on kiinteä, testattu ja hyväksytty.
- Duplicate: vian elinkaaressa, jos vika toistetaan kahdesti tai kahdessa viassa mainitaan sama käsite viasta, yhden vian tila muutetaan muotoon ”duplicate”.
- hylätty: jos Kehittäjä kokee, ettei vika ole aito, hän hylkää vian. Sitten vian tila muutetaan ”hylätyksi”.
- lykätty: jos vika vaihdetaan lykättyyn tilaan, vian odotetaan korjaantuvan seuraavissa julkaisuissa.
kyse oli vian elinkaaresta ja vikojen Hallintaprosessista. Katsotaan, mitkä ovat manuaalisen testauksen haasteet.
manuaalisen testauksen haasteet
LAADUNVARMISTUSTESTAAJIEN suorittamaa sovelluksen manuaalista testausta kutsutaan manuaaliseksi testaukseksi. Tässä, kaikki testit on suoritettava manuaalisesti jokaisessa ympäristössä, käyttäen eri tietokokonaisuuden ja onnistumis – / epäonnistumisnopeus jokaisen tapahtuman olisi tallennettava.
yllä olevassa kuvassa näkyy mies, joka tarkastaa kirjatut tapahtumat manuaalisesti. Voit helposti ilmoittaa haasteita, että hän on edessään voi aiheuttaa väsymystä, ikävystyminen, viivästyminen työssä, virheitä ja virheitä, koska manuaalista työtä. Tämä johti Automaatiotestauksen syntyyn.
nyt pureudutaan ohjelmistotestauksen opetusohjelman viimeiseen aiheeseen ja katsotaan, miten Automaatiotestaus päihittää manuaalisen testauksen.
Automaatiotestaus vs manuaalinen testaus
Automaatiotestaus voittaa manuaalisen testauksen joka kerta. Miksi? Koska se on supernopea, vaatii paljon vähemmän investointeja inhimillisiin voimavaroihin, ei altis virheille, testien usein suorittaminen on mahdollista, tukee regressiotestausta ja myös toiminnallista testausta.
otetaan esimerkki ja ymmärretään tämä. Sano, että sinulla on kirjautumissivu ja sinun täytyy tarkistaa, jos kaikki kirjautumisyritykset onnistuvat, niin se on todella helppo kirjoittaa pala koodia, joka vahvistaa, Jos kaikki tapahtuma/ kirjautumisyritykset ovat menestys tai ei (automatisoitu testitapauksen suoritus).
kaikki nämä testit voidaan konfiguroida siten, että niitä testataan erilaisissa ympäristöissä ja verkkoselaimissa. Ei vain että, myös voit automatisoida sukupolven tulos tiedosto, ajoittamalla sen tiettyyn aikaan päivän aikana. Sitten voit myös automatisoida sukupolvi raportteja perustuu näihin tuloksiin ja mitä ei.
tärkeää tässä on, että automaation testaus tekee testaajan työstä paljon yksinkertaisempaa. Katso yllä oleva kuva, jossa näkyy rennompi ympäristö, jossa sama testaaja toimii. Jos haluat tietää enemmän Automaatiotestauksesta ja laajalti käytetystä Automaatiotestaustyökalusta Seleniumista, voit viitata tähän Selenium-opetusohjelmaan.
kyse oli siitä, miten automaatiotestaus säkenöi ohjelmistotestauksen saralla. Se tuo meidät loppuun artikkelin Ohjelmistojen testaus opetusohjelma. Toivottavasti löysit sen informatiivinen ja se on auttanut lisäarvoa tietosi.
jos tämä ”ohjelmistotestauksen opetusohjelma” oli mielestäsi merkityksellinen, tutustu Edurekan live-online Selenium Certification Training-koulutukseen.edureka on luotettava verkko-oppimisyritys, jolla on yli 250 000 tyytyväistä opiskelijaa ympäri maailmaa.