As discussed in the first lecture the warm-up task is to pick a testing technique and give a short description of it. Publish the description as a comment to this blog post. You can use Finnish or English. Include links to reference material if relevant. If possible give a concrete example. If you are having problems in finding material to a technique, please contact us (course instructors).
List of techniques (mark your first name and first letter of last name after your selection): https://docs.google.com/spreadsheet/ccc?key=0Ak7z0t62SOIkdDdXT3JlVm42T2FPREZUb3FJQnU2dUE#gid=0
A couple of good places to start hunting materials:
http://www.testingeducation.org/BBST/
http://www.satisfice.com/
http://www.developsense.com/resources.html
Funktionaalinen testaus (function testing)
ReplyDeleteTestaustapa, jolla pyritään varmentamaan ohjelman kaikkien toimintojen oikeanlainen toiminta määritettyjen spesifikaatioiden mukaan. Funktionaalisessa testauksessa ei tarvitse tietää ohjelman sisäisestä rakenteesta, koska testaus tapahtuu ainoastaan syötteiden ja ohjelman ulostulon avulla (black box testing).
Funktionaalinen testaus voidaan rajata viiteen eri vaiheeseen: ohjelman toimintojen ymmärtäminen, testisyötteen luonti, testisyötteen tulosten laskenta ohjelman spesifikaatioiden perusteella, testisyötteen ajaminen ohjelmalla ja testisyötteen ulostulon vertaus spesifikaatioista laskettuihin tuloksiin.
Esimerkki: summan tarkastusohjelman funktionaalinen testaus
Ensimmäiseksi tutustutaan tarkastusohjelman toimintoihin (tässä tapauksessa ohjelman ainoa toiminto on antaa ulostulona syötteenä annetun summan tulos), toiseksi luodaan testisyötteitä (1+1, 1+3, ... 4+2), kolmanneksi lasketaan summat (2, 4, ..., 6), neljänneksi syötetään testisyötteet tarkastusohjelmalle ja viidenneksi verrataan onko tarkastusohjelman ulostulot yhtenevät speksien mukaan laskettuihin tuloksiin.
http://www.guru99.com/functional-testing.html
Stress testing
ReplyDeleteStressitestauksessa testattavaan järjestelmään kohdistetaan normaaliolosuhteita suurempi kuormitus. Testauksen painopisteenä on saada tietoa järjestelmän virheensietokyvystä, saatavuudesta ja toimivuudesta suuren laskentakuorman alla. Stressitestausta pitää tavallisesti suorittaa järjestelmille, joissa kuormituspiikit ovat yleisiä ja järjestelmille, joiden toiminta pitää olla taattua suurenkin rasituksen aikana.
Webserveri on yleinen esimerkki järjestelmästä jota stressitestataan. Web sivujen kävijämäärät saattavat usein ajoittua tiettyyn kellonaikaan, jolloin kävijöitä on erityisen paljon tai palveluun saatetaan kohdistaa palvelunestohyökkäys, jolloin järjestelmän pitäisi suoriutua suuresta äkillisestä dataliikenteestä. Toinen esimerkki on ydinvoimala, joiden järjestelmien pitää olla hyvin stressitestattuja, katastrofaalisten seurauksien välttämiseksi.
http://en.wikipedia.org/wiki/Stress_testing_(software)
Regression testing
ReplyDeleteRegressiotestauksella tarkoitetaan ohjelman uudelleentestaamista muutoksen jälkeen. Regressiotestauksen tavoitteena on paljastaa muutoksen mahdollisesti aiheuttamat virheet ohjelmassa ennen muutosta olleeseen toiminnallisuuteen. Tämä tehdään testaamalla ohjelmaa regressiotestitapauksilla, joista osa on peräisin ohjelman vanhasta testijoukosta ja osa on uusia, jo aiemmin testatun toiminnallisuuden testaamiseen tarkoitettuja
regressiotestitapauksia.
Tällä hetkellä yleisin tapa suorittaa regressiotestaus on käyttää uudelleen kaikki vanhat testitapaukset. Tehokkain ja eniten tutkittu tapa tehostaa regressiotestausta on vähentää regressiotestauksessa ajettavien vanhojen testitapausten määrää käyttämällä regressiotestien valintatekniikoita.
http://his.uku.fi/avointa/julkaisut/Regressiotestaus_ja_testien_valintatekniikat.pdf
Bug Bash
ReplyDeleteBug Bash eli buginmetsästys on organisaation sisäinen testaustapa, jossa työntekijät joukkueittain etsivät virheitä etukäteen ilmoitetusta aiheesta. Testin johtoryhmä ilmoittaa päivämäärän, aiheen, sekä muun ohjeistuksen ryhmille. Ryhmät voivat koostua ohjelmoijien lisäksi sihteereistä, myyjistä, käytännössä kenestä tahansa saatavilla olevasta työntekijästä. Testin kesto on yleensä intensiivinen esim. yhden päivän.
Testin johtoryhmä voi motivoida testaajia palkitsemalla niitä ryhmiä, jotka löysivät eniten virheitä annetuista aiheista. Palkintoina voi olla esimerkiksi sosiaalisen tapahtuman järjestäminen (vedetään phönttöö yhdessä) testauksen päätyttyä.
http://en.wikipedia.org/wiki/Bug_bash
http://www.cs.utu.fi/opinnot/kurssit/Salo/kevat2011/tekniikkakartta.pdf
Scenario Testing
ReplyDeleteSkenaariotestauksessa testaajat asettuvat loppukäyttäjän rooliin varmistaakseen, että softa toimii kunnolla. Testauksessa on tarkoitus luoda realistisia tapauksia, joita loppukäyttäjien oletetaan kohtaavan. Skenaariotestaus auttaa löytämään paljon vikoja, joita ei muilla testaustyyleillä löydetä. Skenaariotestaaminen on hyvin tärkeää monimutkaisille tapahtumille, ja end-to-end toiminnan tutkimiseen.
http://www.softwaretestingmentor.com/articles/what-is-scenario-testing.php
Specification-based testing
ReplyDeleteSpesifikaatio pohjaisessa testaamisessa yksinkertaisuudessaan testataan että softa toimii määritettyjen spesifikaatioidensa mukaisesti. Eli käytännössä testataan toimiiko ohjelma väitetyllä tavalla. Tässä kuitenkin piilee spesifikaatio pohjaisen testauksen suurin ongelma, määritelläänkö spesifikaatiossa tarkasti mitä ohjelman pitää missäkin tapauksessa tehdä? Spesifikaatio pohjainen testaus voi olla funktionaalista tai ei-funktionaalista.
Esimerkki: softan pitää specifikaation mukaan palauttaa kahden eri taulun summa tietyssä tapauksessa. Spesifikaatio ei kuitenkaan välttämättä tässä tapauksessa ota kantaa ollenkaan taulujen sisältöön, numeroita, stringejä jne. Spesifikaatio voidaan testataan esim taulujen arvoilla 2 ja 3 jolloin softan tulisi speksin mukaan palauttaa 5.
http://en.wikipedia.org/wiki/Software_testing
http://testingeducation.org/BBST/specbased/
Guerilla testing
ReplyDeleteJos resurssit eivät riitä suunnitelmalliseen ja laajaan käyttöliittymän ja -kokemuksen testaamiseen, sissitestausta voidaan käyttää nopeampana ja halvempana tapana ohjaamaan kehitystä. Oikeiden loppukäyttäjien kokemus järjestelmän käytöstä on tärkeää, jotta kehittäjien omat mieltymykset, käytännöt ja väistämättömät kompromissit eivät veisi kehitystä vinoon - tavoitteena tutkimuksen informoima design.
Laajan tutkimuksen ja testauksen ollessa mahdotonta, esim. kehittäjäorganisaation politiikan takia, pyritään sissitestauksella saavuttamaan edes pieni määrä hyvää testausta, joka on luonnollisesti parempi kuin ei mitään testausta. Vähillä resursseilla voidaan saada selville oikeita puutteita ja huomionarvoisia kehityssuuntia, joiden perusteella voidaan tarvittaessa tutkia ja testata järjestelmää tarkemmin - esittämällä oikeaa dataa on myös helpompi saada lisää resursseja tarkempaan ja strukturoidumpaan testaukseen. Maksimaalisen kurinalaisuuden, ajankäytön ja kustannusten sijaan pyritään käyttämään vain tarvittava määrä näitä ominaisuuksia, oikeassa ajassa ja paikassa.
Esimerkiksi laboratorio-olosuhteissa tehtävä, käyttäjien läsnäoloa vaativa käytettävyystestaus voidaan suorittaa etätestauksensa (remote testing), jolloin säästetään huomattavasti järjestelyissä, ajassa ja kustannuksissa. Lisäksi saavutetaan realistisempi käyttöympäristö, jos testaajat käyttävät omia tietokoneitaan. Toinen sissitestaustaktiikka on "väijytystestaus" (ambush guerilla testing), jossa lähestytään ihmisiä esim. jossain julkisessa paikassa, ja pyydetään heitä käyttämään järjestelmää hetken ajan. Tarkasti suunnitellun ja optimaalisen otannan järjestelmän kohdeyleisöstä sijaan pyritään saamaan suuntaa-antava otanta käyttökokemuksia testattavasta järjestelmästä ohjaamaan tulevaa kehitystä ja testausta.
Molemmissa esimerkkitapauksissa käyttötapahtuma ja käyttäjän reaktiot tallennetaan analyysiä varten jollain screencast/webcam -kombolla, tai dedikoidulla työkalulla, esim. http://silverbackapp.com/.
http://uxmag.com/articles/getting-guerrilla-with-it
http://uxmag.com/articles/doing-more-with-remote-research
http://www.currybet.net/cbet_blog/2010/06/10-tips-for-ambush-guerilla-us.php
User Acceptance Testing (UAT) vaihe jolloin ohjelmisto testataan “oikeassa elämässä” loppukäyttäjillä. UAT:n tavoitteena on havainnoida tukeeko ohjelmisto käyttäjien päivittäisten toimintojen suorittamista ja siten täyttää sen toiminnalliset vaatimukset. UAT:n on jossain asiayhteyksissä rinnastettavissa käytettävyystestaukseen (usability testing). UAT voidaan aloittaa heti vaatimusmäärittelyn jälkeen ja sitä jatketaan aina ohjelmiston viimeiseen testaukseen saakka.
ReplyDeleteUAT:ssä suurta roolia näyttelevät siis lopulliset käyttäjät. Nykyaikaiset iteratiiviset sovelluskehitysmenetelmät mahdollistavat käyttäjien osallistamisen kehitysprojekteihin useammin ja aikaisemmassa vaiheessa. UAT-testien tekeminen jo projektin alkuvaiheessa paljastaa paljon asioita, mutta ennen kaikkea mittaa sovelluksen laatua. Käyttäjien kanssa testaaminen auttaa löytämään virheitä ja epäkohtia ohjelmistosta, jotka muutoin havaittaisiin myöhemmin tai mahdollisesti jäisivät huomaamatta. Näiden vajavaisuuksien löytäminen aikaisin kehitysvaiheessa vähentää kuluja ja parantaa lopullisen ohjelmiston laatua.
Tärkeitä pointteja UAT:ssä:
- Vaatimusmäärittely tulee tehdä hyvin, jotta testit olisivat todenmukaisia ja käyttäjät on osallistettava testien suunnitteluun jo projektin alkuvaiheessa
- Ohjelmisto tulee suunnitella siten, että testien tekeminen olisi helppoa
- Käytettävyystestien tekeminen aina projektin alkuvaiheista lähtien.
http://www.develop.com/useracceptancetests
User testing tai Usability testing on testausmuoto, jossa käytetään käyttäjiä vailla tietoa ohjelmiston sisäisestä rakenteesta ja toimintatavasta jonkin tietyn ominaisuuden testaamiseen. Sopivimpia kohteita Usability testingiin ovat verkkosivut ja käyttöliittymävetoiset sovellukset.
ReplyDeleteUsability testing tapahtuu antamalla käyttäjille tietyt tehtävät toteutettavaksi. Tämän aikana testin valvojat kirjoittavat muistiinpanoja havainnoistaan. Testin loputtua käyttäjiä haastatellaan palautteen saamiseksi. Tämän testaustavan käyttäjät ovat siis projektinulkoisia henkilöitä, joilla ei ola aiempaa kokemusta tuotteesta.
http://en.wikipedia.org/wiki/Usability_testing
Scripted testing
ReplyDeleteScripted testing voitaisiin kääntää käsikirjoitetuksi testiksi. Scripted testingin ideana on testatessa noudattaa ennalta kirjoitettua dokumenttia, johon on kuvailtu testitapaus eli sarja erilaisia testejä tehtäväksi tietyssä järjestyksessä. Scripted testingissä on yleensä kaksi eri roolia, jotka ovat testin suunnittelija ja testaaja. Testin suunnittelija tekee etukäteen testitapaukset, jotka testaaja sitten suorittaa.
Etuna on se, että vain testin suunnittelijan tarvitsee olla kokenut testaaja, ja testaajat voivat olla aloittelijoita. Lisäksi scripted testing mahdollistaa tarkan suunnittelun ja ennalta-arvattavuuden. Perustestaaminen on kuitenkin tylsää ja yksitoikkoista.
http://www.intexsoft.com/blog/item/73-scripted-testing-vs-exploratory-testing.html
Load testingissä eli kuormitustestauksessa pyritään selvittämään, miten järjestelmä toimii eri kuormilla ja miten kovalla kuormalla se ei enää toimi normaalisti. Samalla tarkoituksena on löytää pullonkaulat, jotta jotain voidaan korjatakin. Load testing on tärkeää erityisesti webbisovelluksissa, mutta myös offline-ohjelmia voidaan testata kuormittamalla esim. suurella datan määrällä.
ReplyDeleteTestiä aloitettaessa on tärkeää selvittää, miten järjestelmä voi tositilanteessa kuormittua. Sitten kehitetään testit, jotka simuloivat kuormaa niin, ettei mikään järjestelmän osa pääse liian helpolla. Tämä tarkoittaa yleensä virtuaalisten käyttäjien simulointia, jotka esim. kirjautuvat palveluun ja tekevät siellä kukin vähän erilaisia asioita samaan aikaan.
Kun kuormaa lisätään niin paljon, että järjestelmän odotetaankin hajoavan, ollaan stressitestauksen puolella.
http://en.wikipedia.org/wiki/Load_testing
http://msdn.microsoft.com/en-us/library/bb924372.aspx
Risk-based testing (RBT) on ohjelmistotestauksen tyyppi, joka painottaa ja priorisoi ominaisuuksien ja funktioiden testausta niihin liittyvien riskien perusteella. Riskiä arvioidaan ominaisuuden tärkeyden sekä epäonnistumisen todennäköisyyden ja seurausten vakavuuden perusteella.
ReplyDeleteKaikkien kriittisempien moduulien löytäminen on ensimmäinen vaihe testauksen priorisoinnissa. Näiden lisäksi on kaksi muuta menetelmää: change-based testing ja regression testing.
Change-based testingissä testaaminen keskittyy erityisesti niihin moduuleihin, joihin tehtiin muutoksia eri versioiden välissä. Regressiotestaus varmistaa, että muutos ei aiheuttanut uusia vikoja ohjelmistoon. Muutos johokin moduuliin voi aiheuttaa virheellistä toimintaa jossakin toisessa moduulissa.
http://en.wikipedia.org/wiki/Risk-based_testing
Localization testing
ReplyDeleteLokalisoinnin jälkeen suoritetaan lokalisaation testausta, jonka avulla selvitetään seuraavia asioita: onko lokalisoitu tuote täysin toimiva, onko tuote kielellisesti virheetön ja onko tuotteessa noussut esiin ongelmia lokalisoinnin myötä. Lokalisaation myötä ilmenneet ongelmat voivat olla luonteeltaan kielellisiä tai terminologisia, tai ne voivat liittyä graafiseen käyttöliittymään tai sen ulkoasuun, tai ne voivat rikkoa lokalisoidun tuotteen toiminnallisuuksia.
http://www.moravia.com/files/download/Best_Practices_in_Localization_Testing.pdf
Esimerkki:
DeleteIslamilaisessa pankkijärjestelmässä käytetään aikojen laskemisessa sekä gregoriaanista että islamilaista kalenteria. Islamilaisessa kalenterissa on 354 päivää eli 11 päivää vähemmän kuin gregoriaanisessa kalenterissa. Tässä tapauksessa pitää testata aikoja vertailemalla molempia kalentereja.
http://softwaretestingguide.blogspot.com/2009/10/explain-localization-testing-with.html
Requirements-based testing
ReplyDeleteVaatimuspohjaisessa testauksessa (requirements-based testing, RBT) pyritään selvittämään, onko jokainen ohjelmalle asetettu vaatimus toteutettu ohjelmassa. Koska vaatimukset ovat useimmiten kirjoitettuja, ne ovat useimmiten myös alati muuttuvia, epätarkkoja, ristiriitaisia ja puutteellisia, mikä luonnollisesti aiheuttaa haasteita testaukselle.
Vaatimuksia on sekä etukäteen määriteltyjä (stated) että ei-määriteltyjä (unstated), ja yleensä vaatimuspohjaisessa testausfilosofiassa on ajateltu, että ilman ensinmainittuja ei testausta voi suorittaa ollenkaan. Muita mielipiteitä kuitenkin on, ja ajatellaan myös, että hyvä testaaja osaa kuitenkin lukea mainittuja vaatimuksia "rivien välistä" ei-mainittuja vaatimuksia silmällä pitäen. Tiukasti pelkkien etukäteen määritettyjen vaatimusten varassa testaaminen on siis mahdollista vain, mikäli vaatimukset on määritelty hyvin täydellisesti - mikä on useimmiten mahdotonta.
Yhtenä periaatteena on myös, että jokainen testitapaus on aina jäljitettävissä johonkin vaatimuksista. Tämäkään ei ole käytännössä aina niin yksinkertaista ja pelkän checklist-tyyppisen lähestymistavan lisäksi pitäisi aina pystyä selittämään syvällisemmin miten tietty testi testaa tiettyä vaatimusta. Samaten jo vaatimusten määrittelyvaiheessa voidaan pyrkiä tekemään vaatimuksia selkeiksi testausta ajatellen käyttämällä testaukseen liittyvää termistöä. Toisaalta usein abstraktimpi taso voi olla parempi ja selkeämpi, myös itse testaustakin ajatellen.
http://www.testingeducation.org/BBST/testdesign/BBSTTestDesign2010f.pdf
http://www.satisfice.com/articles/requirements_based_testing.pdf
Usability testing
ReplyDeleteUsability Testing eli käytettävyystestaus on tapa, jossa tuotetta pyritään parantamaan lopullisten käyttäjien avustuksella jo kehitysvaiheessa. Käyttäjät pyrkivät suorittamaan heille normaaleita tehtäviä, joiden perusteella on tarkoitus tunnistaa käytettävyysongelmia, kerätä tietoa sekä saada suoraa palautetta ohjelman kohdekäyttäjiltä.
Testausta tulisi suorittaa jo aikaisessa vaiheessa ja useaan otteeseen, jotta pystyttäisiin puuttumaan epäkohtiin ajoissa, joka taas säästää aikaa ja työtä. Juuri aikaisessa vaiheessa saatu palaute käyttäjiltä ja epäkohtiin puutuminen on etuna perinteisemmillä tekniikoilla toteutettuihin tuotteisiin, jossa ensimmäiset palautteet voivat tulla vasta juuri ennen tuotteen valmistumista beta-testauksessa. Käytettävyystestaus sopii hyvin yhteen iteratiivisen tuotekehityksen kanssa.
Käytettävyystestauksen kulku:
Testitehtävien suunnittelu
-Mitä? Miksi? Missä? Milloin? Miten? Ketkä?
Testitehtävien valmistus
Käyttäjien valinta
Testaus
Analysointi ja raportointi
Mahdollisten muutosten teko
Mahdollinen uusi testaus
http://www.usability.gov/methods/test_refine/learnusa/index.html
DeleteSmoke testing
ReplyDeleteSmoke testingin on testausta, joka suoritetaan aina ensimmäiseksi ennen muita testejä. Smoke testingin tarkoituksena on varmistaa, että ohjelman kriittiset osat toimivat, eikä siinä ole katastrofaalisia virheitä. Testauksessa testattavan tuotteen tärkeimmät osat testataan pintapuolisesti, mutta mitään osaa ei testata syvällisesti.
Smoke testingin ideana on karsia pois sellaiset ohjelmat, jotka ovat niin rikki ettei niiden tarkempi testaus ole kannattavaa, ennen kuin suuremmat viat on korjattu.
Esimerkkejä smoke testingistä: Käynnistä ohjelma ja katso kaatuuko se, toimiiko GUI jne...
http://www.guru99.com/smoke-sanity-testing.html
Käyttöliittymätestaus (user interface testing)
ReplyDeleteKäyttöliittymätestauksella varmistetaan, että käyttäjän suorittamista toimenpiteistä, kuten näppäimistön painalluksista tai valikoiden/nappuloiden/yms. klikkaamisesta seuraa haluttu, sekä yhtenäinen lopputulos käyttöliittymässä. Testattaessa ei tarvitse välttämättä tietää ohjelman sisäisestä toiminnasta, vaan ainoastaan käyttäjän toimenpiteen tuottama oletettu lopputilanne.
Yleinen tapa on testata käyttöliittymää manuaalisesti ja todeta sen toimivuus. Tämä lähestymistapa on kuitenkin hidas ja virhealtis. Myös automaattista testausta voidaan toteuttaa ohjelmilla, jotka suorittavat tiettyjä skriptattuja käyttöskenaarioita toistuvasti halutulla aikavälillä. Automaattiseen käyttöliittymätestaukseen on olemassa myös useita valmiita ohjelmistokehyksiä.
Käytännössä automatisoituun käyttöliittymätestaukseen vaadittava vaivannäkö kumoaa usein siitä saatavan hyödyn. Esimerkiksi jatkuvasti muuttuvassa käyttöliittymässä automatisoituja testejä joudutaan rakentamaan jatkuvasti uudelleen.
http://www.appperfect.com/products/application-testing/app-test-gui-testing.html
Deletehttp://developer.android.com/tools/testing/testing_ui.html
http://en.wikipedia.org/wiki/Graphical_user_interface_testing
Performance testing (suorituskykytestaus)
ReplyDeleteSuorituskykytestauksessa pyritään mittaamaan sovelluksen ei-toiminnallisia ominaisuuksia tietyllä kuormalla. Näitä ovat esimerkiksi: [1]
-suoritusteho (esim. palveltujen asiakkaiden määrä serverissä)
-resurssien käyttöaste (esim. verkon kaistankäyttö)
-vasteaika (esim. käyttöliittymän nopeus)
-saatavuuden taso käyttäjälle (esim. pankkipalvelujen saatavuus)
Testit mahdollistavat eri sovellusten vertailemisen keskenään sekä huonosti käyttäytyvän osa-alueen identifioimisen.[3]
Suorituskykytestit suoritetaan usein käyttäen automatisoituja testejä, jotka simuloivat todellisia tilanteita. Nämä simulaatiot perustuvat usein sovelluksen käyttöympäristöstä kerättyihin tilastotietoihin. Testit koostuvat useista ns. injektoivista servereistä, joista jokainen simuloi käyttäjäjoukkoa ja niiden toimia.[1] Suorituskykytestaukseen voidaan sisällyttää stressitesti, jolloin saadaan tietoa myös siitä miten järjestelmä käyttäytyy kun normaalit kuormatasot ylittyvät.[3]
Suorituskyvyn vaatimukset tulisi ottaa mukaan suunnitteluun mahdollisimman aikaisin sovelluksen kehityskaaressa. Tämän laiminlyöminen johtaa usein vakaviin ongelmiin, kun suorituskykytestaus aloitetaan vasta kehityksen loppupuolella: Sovelluksen valmistuminen usein viivästyy eikä ongelmien täydelliseen korjaamiseen ole riittävästi aikaa. Pahimmassa tapauksessa koko sovelluksen arkkitehtuuria joudutaan muuttamaan paremman suorituskyvyn vuoksi.[1][2]
[1] The Art of Application Performance Testing, 1st Edition
, Ian Molyneaux, 2009
[2] http://www.cs.helsinki.fi/u/paakki/gan.pdf
[3] http://en.wikipedia.org/wiki/Software_performance_testing
All pairs tai pairwise testaus perustuu virheiden löytämiseen valittujen syöteparien avulla. Suurin osa virheistä yleensä saadaan tunnistettua jo jopa yhdellä tai kahdella harkitusti valitulla syötteellä.
ReplyDeleteTavallisesti mahdollisien testitilanteiden määrä kasvaa räjähdysmäisesti syötteiden määrään nähden. All pairs testaus pitää testimäärän pienenä kun syötteistä valitaan kattavasti muutamia arvoja ja testataan yksinään sekä kaikkina erillaisina syötepareina. Koska yleisimmät virheet ovat yhden tai kahden syötteen aiheuttamia niin tälläisellä testaustekniikalla saadaan kohtuullisen hyviä tuloksia.
All pairs testaaminen on kohtuullisen kattavaa mutta parhaimmillaan vain kompromissi valtavan testimäärän ja testaus tehokkuuden väliltä.
http://www.youtube.com/watch?v=kFH4QnymGGc
http://en.wikipedia.org/wiki/All-pairs_testing
Interoperability testing
ReplyDeleteInteroperability testing voidaan suomentaa esimerkiksi yhteensopivuustestaukseksi. Yhteensopivuustestauksessa testataan useiden eri tahojen tuottamien ohjelmistojen yhteensopivuutta ja kommunikaatiota koko järjestelmän kannalta. Tänä päivänä monet järjestelmät ovatkin niin suuria, että niitä ei enää pystytä tuottamaan yhden tahon puolesta ja eri ohjelmistot on saatava keskustelemaan keskenään aina ja varmasti.
Yhteensopivuustestauksessa käytetäänkin tilanteesta riippuen useita muita testitekniikoita, kuten hyväksymistestejä. Vaikka ohjelmistot tuotetaankin tunnettuja standardeja käyttäen ja testataan tarkasti, ei voida olla varmoja, että lopullisessa sijoitusympäristössä kaikki toimii yhdessä kuten pitäisi.
Yhteensopivuustestaus onkin usein hyvinkin työllästä ja se tulee lähes poikkeusetta suorittaa lopullisessa sijoitusympäritössä. Tavoitteena on varmistaa erillisten ohjelmistojen saumaton toiminta keskenään ja täten taata koko järjestelmän toimivuus.
http://www.etsi.org/website/aboutetsi/howwework/testingandinteroperability.aspx
http://nresult.com/quality-assurance/interoperability-testing/
Beta Testing
ReplyDeleteBetatestaus on vahvasti sidoksissa Alpha-testaukseen, joka suoritetaan normaalisti aina ennen Betatestausta. Betatestaus on normaalissa kehityssyklissä ohjelmiston viimeinen vaihe ennen sen julkaisua (RC:tä, release candidatea). Beta-testauksen ideana on julkaista ohjelman "prototyyppi" (beta-versio) tietylle määrälle ihmisiä. Ohjelmiston beta-versio on usein ensimmäinen versio, joka julkaistaan ohjelmistoa kehittäneen firman ulkopuolelle.
Beta-version käyttäjiä kutsutaan betatestaajiksi. Betatestaajat ovat usein yrityksen mahdollisia tai jo olemassaolevia asiakkaita, jotka voivat suostua testaamaan (käyttämään) ohjelmaa ilmaiseksi. Betatestaajia houkutellaan usein erilaisilla porkkanoilla, kuten alennuksilla valmiista versiosta, mutta usein pelkkä mahdollisuus päästä kokeilemaan ohjelmaa "etukäteen" riittää porkkanaksi. Betatestausta voidaan pitää eräänlaisena bruteforceamisena, jossa toivotaan, että testaajien suuri määrä aiheuttaa kaikkien mahdollisten bugien löytymisen (ja raportoinnin).
http://msdn.microsoft.com/en-us/library/windowsphone/help/jj215598%28v=vs.105%29.aspx
http://en.wikipedia.org/wiki/Software_release_life_cycle
Boundary testing
ReplyDeleteBoundary testingissä luodaan testikeissejä käyttämällä syötearvoina minimi ja maksimi ääriarvoja jotka ovat annettujen rajojen sisällä ja arvoja jotka ovat juuri ja juuri rajojen ulkopuolella. Rajojen ulkopuolella olevien arvojen pitäisi synnyttää jonkinlainen virheilmoitus. On myös hyvä testata, miten ohjelma suhtautuu syötteeseen arvolta null.
http://sqa.fyicenter.com/FAQ/Software-Testing-Methodolog/What_s_Boundary_Test.html
http://en.wikipedia.org/wiki/Boundary-value_analysis
State based testing (SBT) eli vapaasti suomennettuna tilapohjainen testaus sopii tilanteisiin, jossa ohjelman tai olion tulos riippuu sen tilasta. Tila voi olla aiemman toiminnan tulos tai muun syötten tuloksen perusteella. SBT sopii myös tilanteeseen missä pitää käydä läpi paljon ohjelma tilamuutoksia. SBT kuvataan yleensä vuokaavioilla esim. UML (ks linkki). Kaaviosta näkyy mitkä tilat ovat sallittuja ja mitkä siirtymät. Kaaviossa kuvataan [TILA/STATE], [TAPAHTUMA/EVENT] esim. testattavab metodin kutsu, [SIIRTYMÄ/TRANSACTION] JA [TOIMINTO/ACTION] esim kutsutaan ulkoista oliota.
ReplyDeleteSBT testin tulee hyväksyä ohjelman ja mallin oikeat syötteet ja tulokset. SBTn kattavuutta voidaan määritellä
esim:
- kaikki tilat&tapahtumat&toiminnot
- kaikki sallitut siirtymät
- kaikki siirtymät (myös ei sallitut)
Testausmetodeja voi olla mm. ekvivalenssiluokkien identifiointi, raja-arvo analyysi, worst-case testaus ja modaalisten luokkien testaus (eli luokkien joiden tila riippuu aikaiesemmasta toiminnasta).
Esimerkki: Pinon testaus.
Komponentit: Pino
Tilat: Tyhjä, täynnä ja vajaa
Toiminnot: Push/pull, vedä ja täytä
http://www.cs.helsinki.fi/u/paakki/software-testing-s05-Ch611.pdf
users.jyu.fi/~sakkinen/testaus/aineisto/Tilatestaus.ppt
C O N S T R A I N T S ( rajoitukset )
ReplyDeleteTestauksessa rajoitukset ovat kaikki tekijät jotka estävät testauksen suorittamista. Yritysmailmasta tuttuja rajoituksia ovat tietenkin aika ja raha. Tekniikan puolelta voi testausta rajoittaa väärät tai huonot määritelmät, dokumentaatio tai lähetymistapa. Lisäksi voidaan laskea testaajien ominaisuudet kuten huono motivaatio, yli kuormitus tai taidon puute rajoittavaksi tekiäksi.
Rajoitteita ei välttämättä pysty poistamaan kokonaan, mutta niiden vaikustusta testaukseen voidaan huomattavasti minimoida kun ne otetaan etukäteen huomioon.
Käyn tässä postissa pari tapausta erittäin lyhyesti läpi:
AIKA JA RAHA
Monilla projekteilla on ennalta määrätty mihin mennessä sen pitää olla valmis ja on myös ennalta arvioutu, kuinka paljon se saa maksaa. Jotta testaus kärsisi mahdollisimman vähän näistä rajoitteista on pyrittävä saamaan projekti näissä rajoissa eli testauksen on oltava ”cost effective”. Testauksen vaatima aika ja resurssit on oltava oikeassa suhteessa projektin aikatauluun ja kustannuksiin.
ITSE TESTAAJA
Testaaja voi itse aiheuttaa yrityksen näkökulmsta rajoitteita testaukselle. Siksi onkin tärkeää että testaajat ovat motivoituneita ja hyvin koulutettuja jotta pystyvät tehokkaasti suoriutumaan tehtävästään.
LÄHTEET:
http://www.msqaa.org/Best_Practices/Quality_Control/TestConstraintsV2.pdf