Sveiki, Habr!
Mano vardas Maksimas Ponomarenko, aš esu „Sportmaster“ kūrėjas. Turiu 10 metų patirtį IT srityje. Jis pradėjo savo karjerą rankinio testavimo srityje, tada perėjo prie duomenų bazių kūrimo. Pastaruosius 4 metus kaupdamas žinias, įgytas testavimo ir kūrimo metu, automatizuoju testavimą DBVS lygiu.
„Sportmaster“ komandoje dirbu šiek tiek daugiau nei metus ir kuriu automatizuotą testavimą viename iš pagrindinių projektų. Balandžio mėnesį vaikinai iš „Sportmaster Lab“ ir aš kalbėjome konferencijoje Krasnodare, mano pranešimas vadinosi „Įrenginio testai DBVS“, ir dabar noriu juo pasidalinti su jumis. Teksto bus daug, todėl nusprendžiau reportažą padalyti į du įrašus. Pirmajame kalbėsime apie automatinius testus ir testavimą apskritai, o antrajame – plačiau pakalbėsiu apie mūsų vienetų testavimo sistemą ir jos taikymo rezultatus.
Pirma, šiek tiek nuobodi teorija. Kas yra automatinis testavimas? Tai testavimas, kuris atliekamas naudojant programinę įrangą, o šiuolaikinėse IT vis dažniau naudojamas kuriant programinę įrangą. Taip yra dėl to, kad įmonės auga, auga jų informacinės sistemos ir atitinkamai auga funkcionalumo, kurį reikia išbandyti, kiekis. Rankinis testavimas tampa vis brangesnis.
Dirbau didelėje įmonėje, kurios leidiniai išeina kas du mėnesius. Tuo pačiu metu visas mėnuo buvo praleistas tam, kad dešimtys testuotojų rankiniu būdu patikrintų funkcionalumą. Nedidelei kūrėjų komandai įdiegus automatizavimą, per pusantrų metų testavimo laiką pavyko sutrumpinti iki 2 savaičių. Mes ne tik padidinome testavimo greitį, bet ir pagerinome jo kokybę. Reguliariai paleidžiami automatizuoti testai ir jie visada atlieka visą į juos įtrauktų patikrų eigą, tai yra neįtraukiame žmogiškojo faktoriaus.
Šiuolaikinės IT pasižymi tuo, kad iš kūrėjo gali būti reikalaujama ne tik parašyti produkto kodą, bet ir parašyti vienetinius testus, kurie tikrina šį kodą.
Bet ką daryti, jei jūsų sistema visų pirma pagrįsta serverio logika? Rinkoje nėra universalaus sprendimo ar geriausios praktikos. Paprastai įmonės šią problemą išsprendžia sukurdamos savo pačių parašytą testavimo sistemą. Tai yra mūsų pačių sukurta automatizuota testavimo sistema, kuri buvo sukurta mūsų projekte ir apie tai kalbėsiu savo pranešime.
Lojalumo testavimas
Pirmiausia pakalbėkime apie projektą, kuriame įdiegėme automatizuotą testavimo sistemą. Mūsų projektas yra „Sportmaster“ lojalumo sistema (beje, apie tai jau rašėme ).
Jei jūsų įmonė yra pakankamai didelė, tada jūsų lojalumo sistema turės tris standartines savybes:
- Jūsų sistema bus labai apkrauta
- Jūsų sistemoje bus sudėtingi skaičiavimo procesai
- Jūsų sistema bus aktyviai tobulinama.
Eikime eilės tvarka... Iš viso, jei vertinsime visus „Sportmaster“ prekės ženklus, tai turime daugiau nei 1000 parduotuvių Rusijoje, Ukrainoje, Kinijoje, Kazachstane ir Baltarusijoje. Šiose parduotuvėse kasdien nuperkama apie 300 tūkst. Tai yra, kas antras 000-3 patikrinimai patenka į mūsų sistemą. Žinoma, mūsų lojalumo sistema yra labai apkrauta. O kadangi ji yra aktyviai naudojama, privalome užtikrinti aukščiausius jos kokybės standartus, nes bet kokia programinės įrangos klaida reiškia didelius piniginius, reputacijos ir kitokius nuostolius.
Tuo pačiu metu „Sportmaster“ vykdo daugiau nei šimtą skirtingų akcijų. Akcijos yra įvairios: yra prekių akcijos, yra skirtos savaitės dienai, yra pririštos prie konkrečios parduotuvės, yra akcijos už kvito sumą, yra už prekių skaičių. Apskritai, neblogai. Klientai turi premijas ir reklamos kodus, kurie naudojami perkant. Visa tai veda prie to, kad bet kokio užsakymo apskaičiavimas yra labai nebanali užduotis.
Algoritmas, įgyvendinantis užsakymų apdorojimą, yra tikrai baisus ir sudėtingas. Ir bet kokie šio algoritmo pakeitimai yra gana rizikingi. Atrodė, kad patys nereikšmingiausi pokyčiai gali sukelti gana nenuspėjamų padarinių. Tačiau būtent tokie sudėtingi skaičiavimo procesai, ypač tie, kurie įgyvendina esmines funkcijas, yra geriausi automatizavimo kandidatai. Dešimčių panašių atvejų tikrinimas ranka užima labai daug laiko. Kadangi įėjimo taškas į procesą nesikeičia, vieną kartą jį aprašę, galite greitai sukurti automatinius testus ir būti tikri, kad funkcionalumas veiks.
Kadangi mūsų sistema aktyviai naudojama, verslas norės iš jūsų kažko naujo, gyvens su laiku ir bus orientuotas į klientą. Mūsų lojalumo sistemoje leidimai išleidžiami kas du mėnesius. Tai reiškia, kad kas du mėnesius turime atlikti visišką visos sistemos regresiją. Natūralu, kad, kaip ir bet kuriame šiuolaikiniame IT, kūrimas iš kūrėjo ne iš karto pereina prie gamybos. Jis atsiranda kūrėjo grandinėje, tada iš eilės pereina per bandymų stendą, išleidžiamas, priimamas ir tik tada patenka į gamybą. Bent jau bandymo ir atleidimo grandinėse turime atlikti visišką visos sistemos regresiją.
Aprašytos savybės yra standartinės beveik bet kuriai lojalumo sistemai. Pakalbėkime apie mūsų projekto ypatybes.
Technologiškai 90% mūsų lojalumo sistemos logikos yra serverio pagrindu ir įdiegta „Oracle“. Delphi veikia klientas, kuris atlieka automatizuoto darbo vietos administratoriaus funkciją. Yra atvirų žiniatinklio paslaugų, skirtų išorinėms programoms (pavyzdžiui, svetainei). Todėl labai logiška, kad jei įdiegsime automatizuotą testavimo sistemą, tai darysime „Oracle“.
„Sportmaster“ lojalumo sistema gyvuoja daugiau nei 7 metus ir buvo sukurta pavienių kūrėjų... Vidutinis kūrėjų skaičius mūsų projekte per šiuos 7 metus buvo 3-4 žmonės. Tačiau per pastaruosius metus mūsų komanda gerokai išaugo, o dabar prie projekto dirba 10 žmonių. Tai yra, į projektą ateina žmonės, kurie nėra susipažinę su tipinėmis užduotimis, procesais ir architektūra. Ir padidėja rizika, kad praleisime klaidas.
Projektui būdinga tai, kad nėra specialių testuotojų, kaip personalo padalinių. Žinoma, yra testavimas, tačiau testavimą atlieka analitikai, be kitų pagrindinių savo pareigų: bendravimo su verslo klientais, vartotojais, sistemos reikalavimų kūrimo ir kt. ir tt... Nepaisant to, kad bandymai atliekami labai kokybiškai (tai ypač dera paminėti, nes kai kuriems analitikams ši ataskaita gali pakliūti į akis), specializacijos ir koncentracijos į vieną dalyką efektyvumas nebuvo panaikintas. .
Atsižvelgiant į visa tai, kas išdėstyta pirmiau, siekiant pagerinti pristatomo produkto kokybę ir sutrumpinti kūrimo laiką, idėja automatizuoti projekto testavimą atrodo labai logiška. Skirtingais lojalumo sistemos egzistavimo etapais pavieniai kūrėjai stengėsi padengti savo kodą vienetų testais. Apskritai tai buvo gana nevienodas procesas, kiekvienas naudojo savo architektūrą ir metodus. Galutiniai rezultatai buvo bendri vienetiniams testams: testai buvo kuriami, naudojami kurį laiką, saugomi versijų failų saugykloje, tačiau tam tikru momentu jie nustojo veikti ir buvo pamiršti. Visų pirma, tai lėmė tai, kad testai buvo labiau susieti su konkrečiu atlikėju, o ne su projektu.
utPLSQL ateina į pagalbą
Ar žinote ką nors apie Stepheną Feuersteiną?
Tai protingas vaikinas, ilgą savo karjeros dalį skyręs darbui su Oracle ir PL/SQL, ir šia tema parašęs nemažai darbų. Viena garsiausių jo knygų vadinasi: „Oracle PL/SQL. Profesionalams“. Stephenas sukūrė utPLSQL sprendimą arba, kaip tai reiškia, Unit Testing sistemą, skirtą Oracle PL/SQL. utPLSQL sprendimas buvo sukurtas 2016 m., tačiau prie jo toliau aktyviai dirbama ir išleidžiamos naujos versijos. Ataskaitų teikimo metu naujausia versija galioja 24 m. kovo 2019 d.
Kas tai. Tai yra atskiras atvirojo kodo projektas. Jis sveria porą megabaitų, įskaitant pavyzdžius ir dokumentus. Fiziškai tai yra atskira schema ORACLE duomenų bazėje su paketų ir lentelių rinkiniu, skirtu vienetų testavimui organizuoti. Diegimas trunka kelias sekundes. Išskirtinis utPLSQL bruožas yra jo naudojimo paprastumas.
Pasauliniu mastu utPLSQL yra vienetinių testų vykdymo mechanizmas, kai vieneto testas suprantamas kaip įprastos Oracle paketinės procedūros, kurių organizavimas atitinka tam tikras taisykles. Be paleidimo, utPLSQL saugo visų jūsų bandomųjų paleidimų žurnalą, taip pat turi vidinę ataskaitų teikimo sistemą.
Pažvelkime į pavyzdį, kaip atrodo vieneto bandymo kodas, įgyvendintas naudojant šią techniką.
Taigi, ekrane rodomas tipinės pakuotės specifikacijos kodas su vienetų testais. Kokie yra privalomi reikalavimai? Prieš paketą turi būti įrašytas „utp_“. Visos procedūros su testais turi turėti lygiai tą patį priešdėlį. Pakete turi būti dvi standartinės procedūros: „utp_setup“ ir „utp_teardown“. Pirmoji procedūra iškviečiama iš naujo paleidžiant kiekvieną įrenginio testą, antroji - po paleidimo.
„utp_setup“, kaip taisyklė, parengia mūsų sistemą atlikti vieneto testą, pavyzdžiui, sukurti bandymo duomenis. „utp_teardown“ - atvirkščiai, viskas grįžta į pradinius nustatymus ir iš naujo nustato paleidimo rezultatus.
Pateikiame paprasčiausio vieneto testo, kuris tikrina įvesto kliento telefono numerio normalizavimą pagal mūsų lojalumo sistemos standartinę formą, pavyzdys. Nėra privalomų standartų, kaip rašyti procedūras su vienetiniais testais. Paprastai iškviečiamas bandomos sistemos metodas, o šiuo metodu grąžintas rezultatas lyginamas su etaloniniu. Svarbu, kad pamatinis rezultatas ir gautas rezultatas būtų lyginamas naudojant standartinius utPLSQL metodus.
Vienetinis testas gali turėti bet kokį patikrinimų skaičių. Kaip matyti iš pavyzdžio, bandomu būdu atliekame keturis iš eilės skambučius, kad normalizuotume telefono numerį ir įvertintume rezultatą po kiekvieno skambučio. Kurdami vieneto testą, turite atsižvelgti į tai, kad yra patikrinimų, kurie niekaip neveikia sistemos, o po kelių jums reikia grįžti į pradinę sistemos būseną.
Pavyzdžiui, pateiktame vieneto teste tiesiog suformatuojame įvestą telefono numerį, o tai niekaip neįtakoja lojalumo sistemos.
O jei vienetinius testus rašome naudodami naujo kliento kūrimo metodą, tai po kiekvieno testo sistemoje bus sukurtas naujas klientas, kuris gali turėti įtakos tolesniam testo paleidimui.
Taip atliekami vienetų testai. Galimos dvi paleidimo parinktys: visų vienetų testų vykdymas iš konkretaus paketo arba konkretaus vieneto bandymo vykdymas konkrečiame pakete.
Taip atrodo vidinės ataskaitų teikimo sistemos pavyzdys. Remdamasis vieneto testo rezultatais, utPLSQL sukuria nedidelę ataskaitą. Jame matome kiekvieno konkretaus patikrinimo rezultatą ir bendrą vieneto testo rezultatą.
6 automatinių testų taisyklės
Prieš pradėdami kurti naują automatizuoto lojalumo sistemos testavimo sistemą, kartu su vadovybe nustatėme principus, kurių turėtų atitikti mūsų būsimi automatizuoti testai.
- Automatiniai testai turi būti veiksmingi ir naudingi. Turime nuostabių kūrėjų, kuriuos būtinai reikia paminėti, nes kai kurie iš jų tikriausiai pamatys šią ataskaitą ir rašo nuostabų kodą. Tačiau net ir jų nuostabus kodas nėra tobulas ir turi, turi ir bus klaidų. Norint rasti šias klaidas, reikalingi automatiniai testai. Jei taip nėra, tai arba rašome blogus autotestus, arba atėjome į negyvą sritį, kuri iš principo nevystoma. Abiem atvejais mes darome kažką ne taip, o mūsų požiūris tiesiog neturi prasmės.
- Turėtų būti naudojami automatiniai testai. Nėra prasmės skirti daug laiko ir pastangų rašant programinės įrangos produktą, įdėti jį į saugyklą ir pamiršti. Bandymai turėtų būti atliekami ir atliekami kuo dažniau.
- Automatiniai testai turėtų veikti stabiliai. Nepriklausomai nuo paros laiko, paleidimo stovo ir kitų sistemos nustatymų, bandomieji važiavimai turėtų duoti tą patį rezultatą. Paprastai tai užtikrina tai, kad automatiniai testai veikia su specialiais testo duomenimis su fiksuotais sistemos nustatymais.
- Automatiniai testai turėtų veikti jūsų projektui priimtinu greičiu. Šis laikas kiekvienai sistemai nustatomas individualiai. Kai kurie žmonės gali sau leisti dirbti visą dieną, o kitiems labai svarbu tai padaryti per kelias sekundes. Kiek vėliau papasakosiu, kokius greičio standartus pasiekėme savo projekte.
- Automatinio testavimo kūrimas turėtų būti lankstus. Nepatartina atsisakyti išbandyti bet kurį funkcionalumą vien dėl to, kad anksčiau to nedarėme ar dėl kitų priežasčių. utPLSQL nenustato jokių apribojimų plėtrai, o Oracle iš principo leidžia įdiegti įvairius dalykus. Dauguma problemų turi sprendimą, tai tik laiko ir pastangų klausimas.
- Dislokuojamumas. Turime keletą stendų, kuriuose turime atlikti bandymus. Kiekviename stende duomenų išvadą galima bet kada atnaujinti. Būtina atlikti projektą su automatiniais testais, kad galėtumėte neskausmingai atlikti visišką ar dalinį jo įrengimą.
O antrame įraše po poros dienų papasakosiu ką nuveikėme ir kokių rezultatų pasiekėme.
Šaltinis: www.habr.com