7 Ohjelmistojen testauksen periaatteet esimerkkeineen

Tämä opetusohjelma esittelee seitsemän ohjelmistotestauksen perusperiaatetta, jotka jokaisen ohjelmistotestaajan ja laadunvarmistuksen ammattilaisen tulisi tietää.

Opitaan testausperiaatteet seuraavasti video esimerkki-

Napauta tätä jos video ei ole saatavilla

Tausta

On tärkeää, että saavutat optimaaliset testitulokset suorittaessasi ohjelmistotestausta poikkeamatta tavoitteesta. Mutta miten päätät, että noudatat oikeaa testausstrategiaa? Tätä varten sinun on noudatettava joitain testauksen perusperiaatteita. Tässä on seitsemän yleistä testausperiaatetta, joita käytetään laajasti ohjelmistoteollisuudessa.

Tämän ymmärtämiseksi harkitse tilannetta, jossa siirrät tiedoston kansiosta A kansioon B.

Mieti kaikkia mahdollisia tapoja testata tätä.

Tavallisten skenaarioiden lisäksi voit testata myös seuraavia ehtoja

• Yritetään siirtää tiedostoa, kun se on auki
• Sinulla ei ole suojausoikeuksia liittää tiedostoa kansioon B
• Kansio B on jaetulla asemalla ja tallennuskapasiteetti on täynnä.
• Kansiolla B on jo samanniminen tiedosto, itse asiassa luettelo on loputon
• Tai oletetaan, että sinulla on testattavana 15 syöttökenttää, joista jokaisella on 5 mahdollista arvoa, testattavien yhdistelmien määrä olisi 5^15

Jos testaisit kaikkia mahdollisia yhdistelmiä, SUORITUSAIKA JA KUSTANNUKSET nousisivat eksponentiaalisesti. Tarvitsemme tiettyjä periaatteita ja strategioita testaustyön optimoimiseksi

Tässä on 7 periaatetta:

1) Kattava testaus ei ole mahdollista

Joo! Kattava testaus ei ole mahdollista. Sen sijaan tarvitsemme optimaalisen määrän testausta sovelluksen riskiarvioinnin perusteella.

Ja miljoonan dollarin kysymys on, kuinka määrität tämän riskin?

Tehdään harjoitus vastataksesi tähän

Mikä toimenpide todennäköisimmin aiheuttaa sinun mielestäsi Operajärjestelmän epäonnistuminen?

Olen varma, että suurin osa teistä olisi arvannut, että avataan 10 erilaista sovellusta samanaikaisesti.

Jos siis testaisit tätä Operajärjestelmässä, ymmärrät, että vikoja löytyy todennäköisesti moniajotoiminnasta ja ne on testattava perusteellisesti, mikä vie meidät seuraavaan periaatteeseen Vika Clusterta

2) Vika Clusterta

Vika Clusterjossa todetaan, että pieni määrä moduuleita sisältää suurimman osan havaituista vioista. Tämä on Pareto-periaatteen soveltaminen ohjelmistojen testaukseen: noin 80 % ongelmista löytyy 20 %:sta moduuleista.

Kokemuksen perusteella voit tunnistaa tällaiset riskialttiit moduulit. Mutta tällä lähestymistavalla on omat ongelmansa

Jos samat testit toistetaan uudestaan ​​​​ja uudestaan, samat testitapaukset eivät enää löydä uusia virheitä.

3) Torjunta-aineparadoksi

Saman torjunta-aineseoksen toistuva käyttö hyönteisten hävittämiseksi viljelyn aikana johtaa ajan myötä siihen, että hyönteiset kehittävät vastustuskykyä torjunta-aineelle, jolloin torjunta-aineet eivät tehoa hyönteisiin. Sama koskee ohjelmistotestausta. Jos suoritetaan sama sarja toistuvia testejä, menetelmä on hyödytön uusien vikojen löytämisessä.

Tämän ratkaisemiseksi testitapaukset on tarkistettava ja tarkistettava säännöllisesti ja lisättävä uusia ja erilaisia ​​​​testitapauksia, jotta voidaan löytää lisää vikoja.

Testaajat eivät voi vain luottaa olemassa oleviin testaustekniikoihin. Hänen on pyrittävä jatkuvasti parantamaan olemassa olevia menetelmiä testauksen tehostamiseksi. Mutta kaiken tämän hikoilun ja kovan testaustyön jälkeen et voi koskaan väittää, että tuotteesi on virheetön. Ajaaksesi kotiin tässä vaiheessa, katsotaanpa tämä video julkisesta julkaisusta Windows 98

Luuletko, että MICROSOFTin kaltainen yritys ei olisi testannut käyttöjärjestelmää perusteellisesti ja vaarantaisi maineensa vain nähdäkseen käyttöjärjestelmän kaatuvan sen julkisen julkaisun aikana!

4) Testaus osoittaa vikoja

Testausperiaate siis sanoo, että – Testaus puhuu vikojen olemassaolosta, ei puhu vikojen puuttumisesta. eli Ohjelmistojen testaus vähentää todennäköisyyttä, että ohjelmistoon jää havaitsemattomia vikoja, mutta vaikka vikoja ei löytyisikään, se ei ole todiste oikeellisuudesta.

Mutta entä jos työskentelet erityisen kovasti, ryhdyt kaikkiin varotoimiin ja teet ohjelmistotuotteestasi 99 % virheettömän. Ja ohjelmisto ei täytä asiakkaiden tarpeita ja vaatimuksia.

Tämä johtaa meidät seuraavaan periaatteeseen, jonka mukaan - Virheen puuttuminen

5) Virheen puuttuminen – virhe

On mahdollista, että ohjelmisto, joka on 99-prosenttisesti bugiton, on edelleen käyttökelvoton. Näin voi käydä, jos järjestelmä testataan perusteellisesti väärän vaatimuksen varalta. Ohjelmistojen testaus ei ole pelkkää vikojen etsimistä, vaan myös sen tarkistamista, että ohjelmisto vastaa liiketoiminnan tarpeita. Virheen puuttuminen on virhe eli vikojen etsiminen ja korjaaminen ei auta, jos järjestelmän rakenne on käyttökelvoton eikä täytä käyttäjän tarpeita ja vaatimuksia.

Tämän ongelman ratkaisemiseksi seuraava testausperiaate sanoo, että varhainen testaus

6) Varhainen testaus

Varhainen testaus – Testaus tulee aloittaa mahdollisimman varhaisessa ohjelmistokehityksen elinkaaressa. Jotta vaatimusten tai suunnitteluvaiheen puutteet havaitaan varhaisessa vaiheessa. On paljon halvempaa korjata Vika testauksen alkuvaiheessa. Mutta kuinka aikaisin testaus kannattaa aloittaa? On suositeltavaa, että aloitat vian etsimisen heti, kun vaatimukset on määritelty. Tästä periaatteesta lisää myöhemmässä opetusohjelmassa.

7) Testaus on kontekstista riippuvaista

Testaus on kontekstista riippuvaista, mikä tarkoittaa periaatteessa sitä, että tapa, jolla testaat verkkokauppasivustoa, eroaa tavasta, jolla testaat kaupallista sovellusta. Kaikki kehitetyt ohjelmistot eivät ole identtisiä. Voit käyttää erilaista lähestymistapaa, menetelmiä, tekniikoita ja testaustyyppejä sovellustyypistä riippuen. Esimerkiksi testaus, mikä tahansa POS-järjestelmä vähittäiskaupassa on erilainen kuin pankkiautomaatin testaus.

Myytti: "Periaatteet ovat vain viitteellisiä. En käytä niitä käytännössä."

Tämä on niin kovin epätosi. Testiperiaatteet auttavat sinua luomaan tehokkaan Testistrategia ja luonnosvirheiden sieppaamiseen testitapaukset.

Mutta testausperiaatteiden oppiminen on aivan kuin oppisi ajamaan ensimmäistä kertaa.

Aluksi, kun opit ajamaan, kiinnität huomiota kaikkiin asioihin, kuten vaihteiden vaihtamiseen, nopeuteen, kytkimen käsittelyyn jne. Mutta kokemuksen myötä keskityt vain ajamiseen, loppu tulee luonnostaan. Sellainen, että keskustelet jopa auton muiden matkustajien kanssa.

Sama pätee testausperiaatteisiin. Kokeneet testaajat ovat sisäistäneet nämä periaatteet sellaiselle tasolle, että he soveltavat niitä ajattelemattakin. Tästä syystä myytti, jonka mukaan periaatteita ei käytetä käytännössä, ei yksinkertaisesti pidä paikkaansa.