Visuaalne testimine erinevates testimismeetodites
Failid
Kuupäev
2012
Autorid
Ajakirja pealkiri
Ajakirja ISSN
Köite pealkiri
Kirjastaja
Tartu Ülikool
Abstrakt
Tänapäeval hakkab üha enam maailmast ning tehnoloogia võimalustest liikuma internetti ning veebi. Kuna kasutusel on ka mitmeid veebibrausereid ning operatsioonisüsteeme, seisavad mitmed tarkvaraarendajad ning -testijad probleemi ees, kus erinevates brauserites näevad rakendused ning veebilehed erinevad välja. Erinevused algavad väikestest tekstinihetest ning lõppevad puudulike elementide, objektide nihete ning lõikumisega. Hetkel kasutatakse enamikus tarkvarafirmades taoliste vigade leidmiseks nn. uurivat testimist. Kuna antud testimine tehakse aga manuaalselt, on see suhteliselt kallis ning ajakulukas. Kuna antud teemavaldkond pole ka väga populaarne teaduse vallas, ei ole hetkel väga palju erinevaid automatiseeritud tööriistu taoliste probleemide avastamiseks.
Olemasolevad tööriistad põhinevad tavaliselt DOM struktuuri võrdlemise meetodil. Kuigi antud meetod on väga efektiivne näiteks dünaamilist sisu omavate veebilehtede testimiseks, on sellel ka mitmeid negatiivseid aspekte. Üks suuremaid on kindlasti kiirus, sest kahjuks on antud tööriistad suhtelised aeglased. Lisaks tekitab probleeme veebibrauserite suur arv ning erinevus- nimelt pole brauseritel väga konkreetseid ja standardiseeritud nõudeid DOM struktuuri koostamisele. See omakorda tekitabki probleeme antud tööriistadega- kuna struktuurid võivad olla erinevad, tekitab see meetod tunduvalt rohkem vale-positiiseid tulemusi.
Üheks suhteliselt uueks tööriistaks on Eestis arendatud Browserbite. Kuna antud tööriist kasutab hoopis teistsugust lähenemist, on see tunduvalt kiirem ja usaldusväärsem. Küll aga huvitab paljusid testijaid küsimus, kas automaatne tööriist on siiski parem kui manuaalne testimine.Uurimaks seda, viisin oma töös läbi katse nii antud tööriista kui ka päris testijatega. Testis kontrolliti 50 veebilehte Browserbite`is ning lasti erinevusi otsida ka 5 testijast koosneval kontrollgrupil (erinevates brauserites). Kuigi võiks arvata, et automaatsed tööriistad on üldjuhul inimestest paremad ning kiiremad, olid tulemused suhteliselt üllatavad - kuigi Browserbite oli tunduvalt kiirem, kui manuaalne testimine, oli leitud vigade arv siiski kontrollgrupil tunduvalt suurem. Nimelt leiti manuaalse testimise teel 10% rohkem vigu kui leidis antud tööriist. Antud protsent pole küll suur, kuid siiski oluline. Taoline erinevus tuli asjaolust, et tööriist ei suutnud leida paljusid väiksemaid objekte puudutavaid vigu. Näiteks erinevused nuppude värvis ning kujus olid raskesti leitavad. Hetkel võib aga selle andeks anda, kuna tööriist on suhteliselt uus ning osaliselt ka alles arendamisjärgus. Lisaks võis mõju avaldada ka Browserbite`i konfiguratsioon. Seega oleks kindlasti huvitav testida antud tööriista uuesti paari kuu kuni poole aasta pärast, kuna siis võivad hetkel olevad kitsaskohad olla parandatud ning tulemused ka tunduvalt erinevad.
As web applications are becoming increasingly important, the developers have to face the problems related to cross-browsing. Different applications and web pages may have a lot of layout issues in different browsers. Tracking these kinds of issues is made even harder, by the variety of operation systems and browser versions in use. Many software companies use exploratory testing for finding these issues, but this is quite time consuming and expensive. There are only a few tools for alleviating these problems by helping find the cross-browsing issues. Most of them use DOM comparison, which means that layout issues are found by comparing different browsers DOM structure of the web page. This method is very simple, but compared to other methods it is very slow and may give a lot of false-positive results as the DOM may differ in many browsers and the method does not take that into account. One of the new automated tool, for finding cross-browsing layout issues is Browserbite. It uses a different approach, which makes it quicker and more reliable. Still a lot of testers are considering between manual testing and automated tools - which is more efficient and superior. Although automated tools become more preferable and save more time (compared to manual testing) they may not be as reliable and effective as manual testing. This thesis showed, that automated tools may not always be better and more efficient than manual testing. Although time spent to perform the tests was almost 5 times smaller with the tool (compared to manual testing), the difference between the number of found issues was remarkable. Although the number of reported false-positive issues was bigger with manual testing, it found over 10% more issues compared to the automated Browserbite tool. This may be caused by many reasons- as the tool is quite new and is still being developed, it may not be programmed to find all the possible faults that can appear in cross-browsing. The configuration may also have had its own part- the tool found very few issues which appeared on small objects. For example, button sizes, shapes and colors went unnoticed quite frequently. Despite this, it can be said that the tool is suitable for regression testing as it is very quick and its user interface allows to analyse issues in a very simple means. It can also be said, that the combination of tester and the tool gives the best solution- as the tool has features that makes testing simpler, issues are easy to find. Therefore, during test planning, you don`t have to consider only one or another approach - a combination of manual and automated testing may give even better solution.
As web applications are becoming increasingly important, the developers have to face the problems related to cross-browsing. Different applications and web pages may have a lot of layout issues in different browsers. Tracking these kinds of issues is made even harder, by the variety of operation systems and browser versions in use. Many software companies use exploratory testing for finding these issues, but this is quite time consuming and expensive. There are only a few tools for alleviating these problems by helping find the cross-browsing issues. Most of them use DOM comparison, which means that layout issues are found by comparing different browsers DOM structure of the web page. This method is very simple, but compared to other methods it is very slow and may give a lot of false-positive results as the DOM may differ in many browsers and the method does not take that into account. One of the new automated tool, for finding cross-browsing layout issues is Browserbite. It uses a different approach, which makes it quicker and more reliable. Still a lot of testers are considering between manual testing and automated tools - which is more efficient and superior. Although automated tools become more preferable and save more time (compared to manual testing) they may not be as reliable and effective as manual testing. This thesis showed, that automated tools may not always be better and more efficient than manual testing. Although time spent to perform the tests was almost 5 times smaller with the tool (compared to manual testing), the difference between the number of found issues was remarkable. Although the number of reported false-positive issues was bigger with manual testing, it found over 10% more issues compared to the automated Browserbite tool. This may be caused by many reasons- as the tool is quite new and is still being developed, it may not be programmed to find all the possible faults that can appear in cross-browsing. The configuration may also have had its own part- the tool found very few issues which appeared on small objects. For example, button sizes, shapes and colors went unnoticed quite frequently. Despite this, it can be said that the tool is suitable for regression testing as it is very quick and its user interface allows to analyse issues in a very simple means. It can also be said, that the combination of tester and the tool gives the best solution- as the tool has features that makes testing simpler, issues are easy to find. Therefore, during test planning, you don`t have to consider only one or another approach - a combination of manual and automated testing may give even better solution.