Tässä opetusohjelmassa esitellään seitsemän ohjelmistojen testausperiaatetta, jotka jokaisen ohjelmistotestaajan ja laadunvalvonnan ammattilaisen tulisi tietää.
7 ohjelmistojen testauksen periaatteet
- Testaus osoittaa vikojen esiintymisen
- Kattava testaus ei ole mahdollista
- Varhainen testaus
- Vikaryhmä
- Torjunta-aineiden paradoksi
- Testaus riippuu kontekstista
- Virheiden puuttuminen
Opi oppimaan testausperiaatteet seuraavalla videon esimerkillä-
Napsauta tätä, jos video ei ole käytettävissä
Tausta
On tärkeää, että saavutat optimaaliset testitulokset samalla, kun suoritat ohjelmistotestausta poikkeamatta tavoitteesta. Mutta kuinka 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 skenaariota, jossa siirrät tiedostoa kansiosta A kansioon B.
Ajattele 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ää tiedosto kansioon B
- Kansio B on jaetussa asemassa ja tallennuskapasiteetti on täynnä.
- Kansiossa B on jo tiedosto, jolla on sama nimi, itse asiassa luettelo on loputon
- Tai oletetaan, että sinulla on 15 testattavaa syöttökenttää, joista jokaisella on 5 mahdollista arvoa, testattavien yhdistelmien määrä olisi 5 15
Jos testaisit kaikki mahdolliset yhdistelmät, projekti SUORITUSAIKA & KUSTANNUKSET nousevat eksponentiaalisesti. Tarvitsemme tiettyjä periaatteita ja strategioita testauksen 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 riskinarvioinnin perusteella.
Ja miljoonan dollarin kysymys on, miten määrität tämän riskin?
Tehdään vastaus tähän
Mikä toiminto saattaa mielestänne todennäköisesti aiheuttaa käyttöjärjestelmän vian?
Olen varma, että useimmat teistä olisivat arvanneet avaavan 10 erilaista sovellusta samanaikaisesti.
Joten jos testaisit tätä käyttöjärjestelmää, huomaat, että vikoja todennäköisesti löytyy monitoimintatoiminnoista ja ne on testattava perusteellisesti, mikä vie meidät seuraavaan vikaklusterointiperiaatteeseemme
2) Vikaryhmä
Defect Clustering, jonka mukaan pieni osa moduuleista sisältää suurimman osan havaituista virheistä. Tämä on Pareto-periaatteen soveltaminen ohjelmistojen testaukseen: noin 80% ongelmista löytyy 20% moduuleista.
Kokemuksen perusteella voit tunnistaa tällaiset riskialttiit moduulit. Mutta tällä lähestymistavalla on omat ongelmansa
Jos samat testit toistetaan uudestaan ja uudestaan, lopulta samat testitapaukset eivät enää löydä uusia vikoja.
3) Torjunta-aineen paradoksi
Saman torjunta-aineseoksen toistuva käyttö hyönteisten hävittämiseen viljelyn aikana johtaa ajan myötä siihen, että hyönteiset kehittävät vastustuskykyä torjunta-aineelle. Täten torjunta-aineiden tehoton vaikutus hyönteisiin. Sama koskee ohjelmistojen testausta. Jos suoritetaan samat toistuvat testit, menetelmä on hyödytön uusien vikojen löytämisessä.
Tämän ratkaisemiseksi testitapauksia on tarkasteltava ja tarkistettava säännöllisesti, lisäämällä uusia ja erilaisia testitapauksia vikojen löytämiseksi.
Testaajat eivät voi vain riippua olemassa olevista testitekniikoista. Hänen on pyrittävä jatkuvasti parantamaan nykyisiä menetelmiä testauksen tehostamiseksi. Mutta vaikka kaikki tämä hiki ja kova työ testauksessa, et voi koskaan väittää, että tuotteesi on virheetön. Jos haluat ajaa kotiin tässä vaiheessa, katsotaan tämä video Windows 98: n julkisesta käynnistämisestä
Luulet, että MICROSOFTin kaltainen yritys ei olisi testannut käyttöjärjestelmäänsä perusteellisesti ja vaarantaisi maineensa vain nähdäkseen käyttöjärjestelmän kaatumisen julkisen käynnistämisen aikana!
4) Testaus osoittaa vikojen esiintymisen
Siksi testausperiaatteessa todetaan, että - Testauksessa puhutaan virheiden olemassaolosta eikä puhuta virheiden puuttumisesta. Ohjelmistojen testaus vähentää havaitsemattomien vikojen todennäköisyyttä ohjelmistoon, mutta vaikka vikoja ei löydy, se ei ole osoitus oikeellisuudesta.
Mutta entä jos työskentelet erityisen kovasti tekemällä kaikki varotoimet ja tekemällä ohjelmistotuotteestasi 99% virhevapaa. Ja ohjelmisto ei täytä asiakkaiden tarpeita ja vaatimuksia.
Tämä johtaa meidät seuraavaan periaatteeseemme, joka toteaa sen - Virheiden puuttuminen
5) Virheen puuttuminen - harhaluulo
On mahdollista, että 99% virhevapaa ohjelmisto on edelleen käyttökelvoton. Näin voi olla, jos järjestelmässä testataan perusteellisesti väärät vaatimukset. Ohjelmistojen testaus ei ole pelkästään vikojen löytämistä, vaan myös sen tarkistamista, että ohjelmistot vastaavat yrityksen tarpeita. Virheen puuttuminen on virhe, eli vikojen löytäminen ja korjaaminen ei auta, jos järjestelmän koontiversio on käyttökelvoton eikä täytä käyttäjän tarpeita ja vaatimuksia.
Tämän ongelman ratkaisemiseksi seuraavassa testausperiaatteessa todetaan, että Early Testing
6) Varhainen testaus
Varhainen testaus - testauksen tulisi alkaa mahdollisimman aikaisessa vaiheessa ohjelmistokehityksen elinkaaressa. Vaatimusten tai suunnitteluvaiheen mahdolliset puutteet havaitaan varhaisessa vaiheessa. On paljon halvempaa korjata vika testauksen alkuvaiheessa. Mutta kuinka aikaisin testin pitäisi alkaa? On suositeltavaa, että aloitat virheen heti, kun vaatimukset määritetään. Lisätietoja tästä periaatteesta myöhemmässä koulutusoppaassa.
7) Testaus riippuu kontekstista
Testaus on kontekstiriippuvainen, mikä tarkoittaa periaatteessa, että tapa, jolla testaat verkkokauppasivustoa, eroaa tavasta, jolla testaat kaupallista hyllystä. Kaikki kehitetyt ohjelmistot eivät ole identtisiä. Voit käyttää erilaista lähestymistapaa, menetelmiä, tekniikoita ja testaustyyppejä sovellustyypistä riippuen. Esimerkiksi testaus, mikä tahansa myyntipisteen POS-järjestelmä on erilainen kuin pankkiautomaatin testaus.
Myytti: "Periaatteet ovat vain viitteellisiä. En käytä niitä käytännössä."
Tämä on niin totta. Testausperiaatteet auttavat sinua luomaan tehokkaan testistrategian ja luonnoksen virheiden havaitsemisesta.
Mutta testausperiaatteiden oppiminen on aivan kuin ajamisen oppiminen ensimmäistä kertaa.
Aluksi, kun opit ajamaan, kiinnität huomiota kaikkiin asioihin, kuten vaihteiden vaihtoon, nopeuteen, kytkimen käsittelyyn jne. Mutta kokemuksen perusteella keskityt vain ajamiseen, loput tulevat luonnollisesti. Sellainen, että keskustelet jopa muiden matkustajien kanssa autossa.
Sama pätee testausperiaatteisiin. Kokeneet testaajat ovat sisäistäneet nämä periaatteet tasolle, jolla he soveltavat niitä jopa ajattelematta. Tästä syystä myytti siitä, että periaatteita ei käytetä käytännössä, ei yksinkertaisesti ole totta.