Hej Habr!
Mi nomiĝas Maxim Ponomarenko kaj mi estas programisto ĉe Sportmaster. Mi havas 10 jarojn da sperto en la IT-kampo. Li komencis sian karieron en manlibrotestado, tiam ŝanĝis al datumbaza evoluo. Dum la lastaj 4 jaroj, akumulante la sciojn akiritajn en testado kaj evoluo, mi aŭtomatigis testadon ĉe la DBMS-nivelo.
Mi estas en la Sportmaster-teamo dum iom pli ol unu jaro kaj disvolvas aŭtomatajn provojn pri unu el la ĉefaj projektoj. En aprilo, la uloj de Sportmaster Lab kaj mi parolis en konferenco en Krasnodar, mia raporto nomiĝis "Unuaj provoj en DBMS", kaj nun mi volas dividi ĝin kun vi. Estos multe da teksto, do mi decidis dividi la raporton en du afiŝojn. En la unua, ni parolos pri aŭtotestoj kaj testado ĝenerale, kaj en la dua, mi pli detale detale pri nia unuoprova sistemo kaj la rezultoj de ĝia aplikado.
Unue, iom enuiga teorio. Kio estas aŭtomata testado? Ĉi tio estas testado, kiu estas farata per programaro, kaj en moderna IT ĝi estas ĉiam pli uzata en programaro. Ĉi tio estas pro la fakto, ke kompanioj kreskas, iliaj informsistemoj kreskas kaj, sekve, la kvanto de funkcieco, kiu devas esti provita, kreskas. Fari manan testadon fariĝas pli kaj pli multekosta.
Mi laboris por granda firmao, kies eldonoj aperas ĉiujn du monatojn. Samtempe, tuta monato estis elspezita por ke dekduo da testistoj permane kontrolas la funkciojn. Dank'al la efektivigo de aŭtomatigo fare de malgranda teamo de programistoj, ni povis redukti testan tempon al 2 semajnoj en jaro kaj duono. Ni ne nur pliigis la rapidecon de testado, sed ankaŭ plibonigis ĝian kvaliton. Aŭtomatigitaj provoj estas lanĉitaj regule kaj ili ĉiam efektivigas la tutan kurson de kontroloj inkluzivitaj en ili, tio estas, ni ekskludas la homan faktoron.
Moderna IT karakterizas per tio, ke programisto povas esti postulata ne nur por skribi produktokodon, sed ankaŭ verki unutestojn, kiuj kontrolas ĉi tiun kodon.
Sed kio se via sistemo baziĝas ĉefe sur servila logiko? Ne ekzistas universala solvo aŭ plej bonaj praktikoj sur la merkato. Kiel regulo, kompanioj solvas ĉi tiun problemon kreante sian propran memskribitan testan sistemon. Ĉi tiu estas nia propra aŭtomate aŭtomatigita testa sistemo, kiu estis kreita sur nia projekto kaj mi parolos pri ĝi en mia raporto.
Testante lojalecon
Unue, ni parolu pri la projekto kie ni deplojis aŭtomatan testan sistemon. Nia projekto estas la lojalecsistemo Sportmaster (cetere, ni jam skribis pri ĝi en ).
Se via kompanio estas sufiĉe granda, tiam via lojaleca sistemo havos tri normajn ecojn:
- Via sistemo estos tre ŝarĝita
- Via sistemo enhavos kompleksajn komputilajn procezojn
- Via sistemo estos aktive plibonigita.
Ni iru en ordo... Entute, se ni konsideras ĉiujn Sportmaster-markojn, tiam ni havas pli ol 1000 vendejojn en Rusio, Ukrainio, Ĉinio, Kazaĥio kaj Belorusio. Ĉirkaŭ 300 aĉetoj estas faritaj en ĉi tiuj vendejoj ĉiutage. Tio estas, ĉiun sekundon 000-3 ĉekoj eniras nian sistemon. Nature, nia lojaleca sistemo estas tre ŝarĝita. Kaj ĉar ĝi estas aktive uzata, ni devas provizi la plej altajn normojn de ĝia kvalito, ĉar ajna eraro en la programaro signifas grandajn monajn, reputaciajn kaj aliajn perdojn.
Samtempe, Sportmaster kuras pli ol cent malsamajn promociojn. Estas diversaj promocioj: ekzistas produktaj promocioj, estas tiuj dediĉitaj al la semajnotago, estas tiuj ligitaj al specifa vendejo, estas promocioj por la kvanto de la kvitanco, estas por la nombro da varoj. Ĝenerale, ne malbone. Klientoj havas gratifikojn kaj reklamajn kodojn, kiuj estas uzataj dum aĉetoj. Ĉio ĉi kondukas al la fakto, ke kalkuli ajnan ordon estas tre ne-triviala tasko.
La algoritmo, kiu efektivigas ordon-prilaboradon, estas vere terura kaj komplika. Kaj ajnaj ŝanĝoj al ĉi tiu algoritmo estas sufiĉe riskaj. Ŝajnis, ke la plej ŝajne sensignifaj ŝanĝoj povus konduki al sufiĉe neantaŭvideblaj efikoj. Sed ĝuste tiaj kompleksaj komputikaj procezoj, precipe tiuj, kiuj efektivigas kritikan funkciecon, estas la plej bonaj kandidatoj por aŭtomatigo. Kontroli dekojn da similaj kazoj permane estas tre tempopostula. Kaj ĉar la enirpunkto en la procezon estas senŝanĝa, priskribinte ĝin unufoje, vi povas rapide krei aŭtomatajn testojn kaj esti certa, ke la funkcio funkcios.
Ĉar nia sistemo estas aktive uzata, la komerco deziros ion novan de vi, vivi kun la tempoj kaj esti kliento-orientita. En nia lojaleca sistemo, eldonoj aperas ĉiujn du monatojn. Ĉi tio signifas, ke ĉiuj du monatoj ni devas plenumi kompletan regreson de la tuta sistemo. Samtempe, nature, kiel en iu moderna IT, evoluo ne tuj iras de la programisto al produktado. Ĝi estiĝas sur la cirkvito de la programisto, poste sinsekve pasas tra la testbenko, liberigo, akcepto, kaj nur tiam finiĝas en produktado. Minimume, sur la provaj kaj eldonaj cirkvitoj, ni devas plenumi kompletan regreson de la tuta sistemo.
La priskribitaj propraĵoj estas normaj por preskaŭ ajna lojalecsistemo. Ni parolu pri la trajtoj de nia projekto.
Teknologie, 90% de la logiko de nia lojaleca sistemo estas servilbazita kaj efektivigita sur Oracle. Estas kliento elmontrita en Delphi, kiu plenumas la funkcion de aŭtomatigita laboreja administranto. Estas elmontritaj retservoj por eksteraj aplikaĵoj (ekzemple retejo). Tial, estas tre logike, ke se ni deplojos aŭtomatan testan sistemon, ni faros ĝin sur Oracle.
La lojaleca sistemo en Sportmaster ekzistas dum pli ol 7 jaroj kaj estis kreita de unuopaj programistoj... La averaĝa nombro da programistoj en nia projekto dum ĉi tiuj 7 jaroj estis 3-4 homoj. Sed dum la pasinta jaro, nia teamo signife kreskis, kaj nun estas 10 homoj laborantaj en la projekto. Tio estas, homoj venas al la projekto, kiuj ne konas tipaj taskoj, procezoj kaj arkitekturo. Kaj estas pliigita risko, ke ni maltrafos erarojn.
La projekto estas karakterizita per la foresto de diligentaj testistoj kiel dungitoj. Estas, kompreneble, testado, sed testado estas farita de analizistoj, krom iliaj aliaj ĉefaj respondecoj: komuniki kun komercaj klientoj, uzantoj, disvolvi sistemajn postulojn ktp. ktp... Malgraŭ tio, ke testado estas farita tre altkvalita (ĉi tio estas precipe taŭga mencii, ĉar iuj el la analizistoj povas kapti la atenton de ĉi tiu raporto), la efikeco de specialiĝo kaj koncentriĝo pri unu afero ne estis nuligita. .
Konsiderante ĉion supre, por plibonigi la kvaliton de la liverita produkto kaj redukti la disvolvan tempon, la ideo de aŭtomatigi testadon en projekto ŝajnas tre logika. Kaj en malsamaj stadioj de la ekzisto de la lojaleca sistemo, individuaj programistoj klopodis kovri sian kodon per unuopaj testoj. Ĝenerale ĝi estis sufiĉe malkongrua procezo, kie ĉiu uzis siajn proprajn arkitekturon kaj metodojn. La finrezultoj estis komunaj al unuotestoj: testoj estis evoluigitaj, uzitaj dum iom da tempo, stokitaj en versionita dosierstokado, sed iam ili ĉesis funkcii kaj estis forgesitaj. Antaŭ ĉio, tio estis pro la fakto, ke la testoj estis ligitaj pli al specifa prezentisto, kaj ne al la projekto.
utPLSQL venas al la savo
Ĉu vi scias ion pri Stephen Feuerstein?
Ĉi tiu estas inteligenta ulo, kiu dediĉis longan parton de sia kariero al laboro kun Oracle kaj PL/SQL, kaj verkis sufiĉe grandan nombron da verkoj pri ĉi tiu temo. Unu el liaj famaj libroj nomiĝas: “Oracle PL/SQL. Por profesiuloj." Estis Stephen kiu evoluigis la utPLSQL-solvon, aŭ, kiel ĝi signifas, Unit Testing-kadron por Oracle PL/SQL. La utPLSQL-solvo estis kreita en 2016, sed ĝi daŭre estas aktive prilaborata kaj novaj versioj estas publikigitaj. En la momento de raportado, la plej nova versio datiĝas de la 24-a de marto 2019.
Kio estas tio. Ĉi tio estas aparta malfermkoda projekto. Ĝi pezas kelkajn megabajtojn, inkluzive de ekzemploj kaj dokumentado. Fizike, ĝi estas aparta skemo en la ORACLE-datumbazo kun aro da pakaĵoj kaj tabeloj por organizi unutestadon. Instalado daŭras kelkajn sekundojn. Karakteriza trajto de utPLSQL estas ĝia facileco de uzo.
Tutmonde, utPLSQL estas mekanismo por ruli unutestojn, kie unuotesto estas komprenita kiel ordinaraj Oracle-araj proceduroj, kies organizo sekvas certajn regulojn. Krom lanĉo, utPLSQL konservas protokolon de ĉiuj viaj testfunkcioj, kaj ankaŭ havas internan raportsistemon.
Ni rigardu ekzemplon de kiel aspektas la unutesta kodo, efektivigita per ĉi tiu tekniko.
Do, la ekrano montras la kodon por tipa paka specifo kun unutestoj. Kio estas la devigaj postuloj? La pako devas esti prefiksita per "utp_". Ĉiuj proceduroj kun testoj devas havi precize la saman prefikson. La pakaĵo devas enhavi du normajn procedurojn: "utp_setup" kaj "utp_teardown". La unua proceduro estas vokita per rekomenco de ĉiu unutesto, la dua - post lanĉo.
"utp_setup", kiel regulo, preparas nian sistemon por ruli unuteston, ekzemple, kreante testajn datumojn. "utp_teardown" - male, ĉio revenas al la originalaj agordoj kaj restarigas la lanĉajn rezultojn.
Jen ekzemplo de la plej simpla unuotesto, kiu kontrolas la normaligon de la enigita klienta telefonnumero al la norma formo por nia lojaleca sistemo. Ne ekzistas devigaj normoj pri kiel verki procedurojn kun unuotestoj. Kiel regulo, voko estas farita al metodo de la testata sistemo, kaj la rezulto redonita de ĉi tiu metodo estas komparata kun la referenca unu. Gravas, ke la komparo de la referencrezulto kaj la akirita okazas per normaj utPLSQL-metodoj.
Unutesto povas havi ajnan nombron da kontroloj. Kiel videblas el la ekzemplo, ni faras kvar sinsekvajn vokojn al la provita metodo por normaligi la telefonnumeron kaj taksi la rezulton post ĉiu voko. Kiam vi disvolvas unuteston, vi devas konsideri, ke ekzistas kontroloj, kiuj neniel influas la sistemon, kaj post kelkaj vi devas reveni al la originala stato de la sistemo.
Ekzemple, en la prezentita unuotesto ni simple formatas la enigan telefonnumeron, kiu neniel influas la lojalecan sistemon.
Kaj se ni skribas unutestojn uzante la metodon krei novan klienton, tiam post ĉiu testo nova kliento estos kreita en la sistemo, kiu povas influi la postan lanĉon de la testo.
Jen kiel unutestoj estas rulitaj. Estas du eblaj lanĉaj opcioj: ruli ĉiujn unutestojn de specifa pako aŭ ruli specifan unuteston en specifa pako.
Jen kiel aspektas ekzemplo de interna raporta sistemo. Surbaze de la rezultoj de la unutesto, utPLSQL konstruas malgrandan raporton. En ĝi ni vidas la rezulton por ĉiu specifa kontrolo kaj la ĝeneralan rezulton de la unutesto.
6 reguloj de aŭtotestoj
Antaŭ ol komenci krei novan sistemon por aŭtomata testado de la lojaleca sistemo, kune kun administrado, ni determinis la principojn, kiujn niaj estontaj aŭtomatigitaj testoj devas plenumi.
- Aŭtotestoj devas esti efikaj kaj devas esti utilaj. Ni havas mirindajn programistojn, kiuj certe devas esti menciitaj, ĉar iuj el ili verŝajne vidos ĉi tiun raporton, kaj ili skribas mirindan kodon. Sed eĉ ilia mirinda kodo ne estas perfekta kaj havas, havas kaj daŭre enhavos erarojn. Aŭtotestoj estas postulataj por trovi ĉi tiujn erarojn. Se ĉi tio ne estas la kazo, tiam aŭ ni skribas malbonajn aŭtotestojn, aŭ ni venis al senviva areo, kiu principe ne estas disvolvita. En ambaŭ kazoj, ni faras ion malbone, kaj nia aliro simple ne havas sencon.
- Aŭtotestoj estu uzataj. Ne havas sencon pasigi multan tempon kaj penadon por verki programaron, meti ĝin en deponejon kaj forgesi ĝin. Testoj devus esti faritaj, kaj funkcii kiel eble plej regule.
- Aŭtotestoj devus funkcii stabile. Sendepende de la horo de la tago, lanĉa stando kaj aliaj sistemaj agordoj, provaj kuroj devas konduki al la sama rezulto. Kiel regulo, ĉi tio estas certigita de la fakto, ke aŭtotestoj funkcias kun specialaj testaj datumoj kun fiksaj sistemaj agordoj.
- Aŭtotestoj devus funkcii je rapideco akceptebla por via projekto. Ĉi tiu tempo estas difinita individue por ĉiu sistemo. Iuj homoj povas pagi labori la tutan tagon, dum aliaj trovas ke estas grave fari ĝin en sekundoj. Mi rakontos al vi iom poste, kiajn rapidecnormojn ni atingis en nia projekto.
- Autotest-evoluo devus esti fleksebla. Ne konsilinde rifuzi testi iun ajn funkcion simple ĉar ni ne faris ĝin antaŭe aŭ pro alia kialo. utPLSQL ne trudas iujn ajn limigojn pri evoluo, kaj Oracle principe permesas efektivigi diversajn aferojn. Plej multaj problemoj havas solvon, ĝi estas nur demando de tempo kaj peno.
- Deplojebleco. Ni havas plurajn standojn, kie ni devas fari testojn. Ĉe ĉiu stando, datuma rubujo povas esti ĝisdatigita iam ajn. Estas necese fari projekton kun aŭtomataj provoj tiel, ke vi povas senpore efektivigi ĝian plenan aŭ partan instaladon.
Kaj en la dua afiŝo post kelkaj tagoj mi rakontos al vi, kion ni faris kaj kiajn rezultojn ni atingis.
fonto: www.habr.com