Automatizuoti ar neautomatizuoti, štai kur klausimas.

Atsakymas – automatizuoti, bet su protu

Pradėkime nuo to, ką realiai galima automatizuoti. Automatizuoti galima funkcinį ir nefunkcinį testavimą. Funkcinio testavimo automatizavimas susiveda į tai, kad programos pagalba įrašome tuos veiksmus, kuriuos atliekame patys, o po to verčiam ją kartoti tuos veiksmus vėl ir vėl, ir vėl…

Su nefunkciniu testavimu yra įdomiau – dalies jo automatizuoti neįmanoma (pvz.: usability arba naudojamumas, GUI – grafinės vartotojo sąsajos), o dalies neįmanoma atlikti rankomis (pvz.: load – apkrovos, stress – stresinis, performance – greitaveika).

Tiek funkcinio, tek nefunkcinio testavimo automatizavimui sukurta N visokiausių įrankių, net nemokamų. Tačiau kiek aš jų mačiau, tiek jie buvo pakankamai sudėtingi išmokti, o kur prasidėdavo įrašytų skriptų koregavimas (pavyzdžiui, kad kaskart vykdant testą būtų paduodami vis kitokie duomenys arba kad iš įkrauto puslapio/SOAP XML imtų kintamuosius ir padavinėtų toliau), ten baigdavosi bet kokia viltis naudingai pritaikyti automatizavimą

Galu gale gavau išbandyti Oracle Application Testing Suite – buvęs Empirix produktas, kurį perpirko ir nuo to momento tobulina Oracle. Jei norite išsibandyti patys, parsisiųsti bandomąją versiją galima iš čia: http://trumpink.lt/?S*c3. Tiesa, tam teks nemokamai užsiregistruoti Oracle svetainėje

Dabar apie patį produktą – jame yra viskas, ko gali prireikti testavimui:

• reikalavimų, testavimo atvejų (su galimybe registruoti rankinius arba automatiškai vykdyti automatinius) ir klaidų valdymo sistema (Oracle Test Manager),
• apkrovos testavimo sistema (Oracle Load Testing for Web Applications), naudojanti tuos pačius skriptus kaip ir
• funkcionalumo testavimo automatizavimo sistema (Oracle Functional Testing for Web Applications), tinkama tiek internetinėms sistemoms, tiek web servisams testuoti,
• Test Manager ir Load Testing administravimo interfeisas (Oracle Application Testing Suite Administrator).

Darbas prasideda nuo administravimo interfeiso, kur sukuriami vartotojai, projektai, “custom” laukai (priskiriami testavimo atvejams, reikalavimams arba klaidoms).

Testavimo atvejų valdymo sistemoje aprašomi rankiniai testavimo atvejai. Po to funkcionalumo testavimui skirtoje sistemoje įrašomi automatinio testavimo scenarijai, kurie vėliau paduodami apkrovos testavimo (panaudojimui apkrovos testams) sistemai ir testavimo atvejų valdymo sistemai (automatiniam vykdymui pagal nustatytą grafiką).

Viskas pakankamai paprasta, ypač perskaičius kelis tūkstančius puslapių dokumentacijos, kuri pateikiama su produktu (kartu su instaliaciniais failais)

Kas liečia skriptų “tiuningą” – čia irgi viskas paprasta, programuoti bendru atveju neturėtų tekti. Viskas atliekama per interfeisą, keliais pelės paspaudimais.

Dar kelios malonios smulkmenos – priedas iššokantiems Internet Explorer dialogams apdoroti ir galimybė nustatyti, kad vykdant apkrovos testavimą būtų arba nebūtų vykdomi funkcionalumo patikrinimai (pvz.: ar puslapyje yra kažkoks tekstas).

Bet…

Visada yra minusų. Keli iš jų, kuriuos pastebėjau:

1. Kaina – vienai darbo vietai kainuoja keliasdešimt tūkstančių litų. Prieš perkant tikrai verta gerai išsibandyti
2. Stabilumas – funkcionalumo testavimui skirta aplikacija pakankamai nestabili, kartais nepataisomai išgadina įrašytus skriptus (1 iš 100).
3. Dar kartą stabilumas – net kai funkcionalumo testavimo aplikacijai pavyksta viską gražiai įrašyti, priklausomai nuo testuojamai sistemai kurti naudojamų technologijų, tai dar nereiškia, kad pavyks skriptą atkartoti (pakankamai retas atvejis, turintis daug workaround’ų).
4. Diegimo ir konfigūravimo paprastumas – įdiegti ir teisingai viską sukonfigūruoti tikrai ušims šiek tiek laiko. Net negalvokit apie Next > Next > OK > Next > Finish variantą
5. Klaidų valdymo sistemos primityvumas – net Bugzilla sugeba daugiau ir teisingiau, bet
6. Test Manager nepalaiko integracijos su trečiųjų šalių klaidų valdymo sistemomis.
7. Kai kuriuose Test Manager puslapiuose kyla problemų su lietuviškų rašmenų atvaizdavimu.
8. Web servisų “fault’ų” tikrinimas – patikrinti galima tik teigiamus WS atsakymus, jei atsakymai pareina “fault’iniai” (su HTTP 500 header’iu) – lieka tik rankinis tikrinimas.

Bet kuriuo atveju pažiūrėję patys pamatysite, kad pliusai šiuo atveju nusveria minusus