Aupa Habr!
Nire izena Maxim Ponomarenko da eta Sportmaster-en garatzailea naiz. 10 urteko esperientzia dut informatika arloan. Eskuzko probetan hasi zuen bere ibilbidea, eta, ondoren, datu-baseen garapenera pasa zen. Azken 4 urteotan, proban eta garapenean lortutako ezagutza pilatuz, probak automatizatzen aritu naiz DBMS mailan.
Urtebete pasatxo daramat Sportmaster taldean eta proba automatikoak garatzen ari naiz proiektu nagusietako batean. Apirilean, Sportmaster Lab-eko mutilek eta biok Krasnodarreko hitzaldi batean hitz egin genuen, nire txostena "DBMS unitatearen probak" deitzen zen, eta orain zuekin partekatu nahi dut. Testu asko egongo da, beraz, txostena bi mezutan banatzea erabaki nuen. Lehenengoan, autotestei eta, oro har, probei buruz hitz egingo dugu, eta bigarrenean, gure unitate-testen sisteman eta bere aplikazioaren emaitzetan sakonduko dut.
Lehenik eta behin, teoria aspergarri bat. Zer da proba automatizatua? Softwarea erabiliz egiten diren probak dira, eta informatika modernoan gero eta gehiago erabiltzen da softwarearen garapenean. Hau da, enpresak hazten ari direlako, haien informazio sistemak hazten ari direlako eta, horren arabera, probatu beharreko funtzionalitate kopurua hazten ari delako. Eskuzko probak egitea gero eta garestiagoa da.
Bi hilabetez behin kaleratzen diren enpresa handi batean lan egin nuen. Aldi berean, hilabete osoa eman zen dozena bat probatzaile eskuz funtzionaltasuna egiaztatzen. Garatzaile talde txiki batek automatizazioa ezartzeari esker, proba-denbora 2 astera murriztu ahal izan genuen urte eta erdian. Probak egiteko abiadura handitu ez ezik, kalitatea ere hobetu dugu. Proba automatikoak aldian-aldian abiarazten dira eta haiek barne hartzen dituzten egiaztapenen ibilbide osoa egiten dute beti, hau da, giza faktorea baztertzen dugu.
IT modernoaren ezaugarria da garatzaile bati produktuaren kodea idaztea ez ezik, kode hori egiaztatzen duten unitate-probak ere idatzi behar izatea.
Baina zer gertatzen da zure sistema nagusiki zerbitzariaren logikan oinarritzen bada? Merkatuan ez dago irtenbide unibertsala edo praktika onak. Oro har, enpresek arazo hau konpontzen dute norberak idatzitako proba sistema propioa sortuz. Hau gure proiektuan sortu zen auto-idatzitako proba automatizatu sistema da eta horri buruz hitz egingo dut nire txostenean.
Leialtasuna probatzea
Lehenik eta behin, hitz egin dezagun proba sistema automatizatu bat zabaldu genuen proiektuari buruz. Gure proiektua Sportmaster leialtasun sistema da (bide batez, dagoeneko idatzi dugu horri buruz ).
Zure enpresa nahikoa handia bada, zure leialtasun sistemak hiru propietate estandar izango ditu:
- Zure sistema oso kargatuta egongo da
- Zure sistemak prozesu informatiko konplexuak izango ditu
- Zure sistema aktiboki hobetuko da.
Goazen ordenan... Guztira, Sportmaster marka guztiak kontuan hartzen baditugu, 1000 denda baino gehiago ditugu Errusian, Ukrainan, Txinan, Kazakhstanen eta Bielorrusian. Denda hauetan 300 erosketa inguru egiten dira egunero. Hau da, segundo bakoitzean 000-3 egiaztapen sartzen dira gure sisteman. Jakina, gure leialtasun sistema oso kargatuta dago. Eta aktiboki erabiltzen denez, bere kalitatearen estandarrik altuenak eman behar ditugu, softwarearen edozein akats diru-galera, ospe- eta bestelako galera handiak suposatzen dituelako.
Aldi berean, Sportmaster-ek ehun promozio ezberdin baino gehiago egiten ditu. Askotariko promozioak daude: badira produktuen promozioak, badira asteko egunari eskainitakoak, badira denda zehatz bati lotuta daudenak, badira ordainagiriaren zenbatekoagatik, badira salgai kopuruagatik. Orokorrean, ez dago gaizki. Bezeroek erosketak egiterakoan erabiltzen diren hobariak eta promozio kodeak dituzte. Horrek guztiak edozein agindu kalkulatzea oso lan hutsala dela dakar.
Eskaerak prozesatzea ezartzen duen algoritmoa izugarria eta konplikatua da. Eta algoritmo honen aldaketak nahiko arriskutsuak dira. Bazirudien aldaketarik hutsalenek nahiko ezusteko ondorioak ekar ditzaketela. Baina hain konputazio prozesu konplexuak dira, batez ere, funtzionalitate kritikoak ezartzen dituztenak, automatizaziorako hautagai onenak. Antzeko dozenaka kasu eskuz egiaztatzeak denbora asko eskatzen du. Eta prozesuan sartzeko puntua aldatu gabe dagoenez, behin deskribatu ondoren, proba automatikoak azkar sor ditzakezu eta funtzionalitateak funtzionatuko duela ziur egon.
Gure sistema aktiboki erabiltzen denez, negozioak zuregandik zerbait berria nahi du, garaiarekin bizi eta bezeroari zuzenduta egongo da. Gure leialtasun sisteman, kaleratzeak bi hilabetean behin ateratzen dira. Horrek esan nahi du bi hilabetean behin sistema osoaren erregresio osoa egin behar dugula. Aldi berean, jakina, edozein informatika modernotan bezala, garapena ez da berehala garatzailetik produkziora pasatzen. Garatzailearen zirkuituan sortzen da, ondoren segidan proba-bankutik igarotzen da, askatu, onartzea eta soilik produkzioan amaitzen da. Gutxienez, proba eta askapen zirkuituetan, sistema osoaren erregresio osoa egin behar dugu.
Deskribatutako propietateak estandarrak dira ia edozein leialtasun-sistemarentzat. Hitz egin dezagun gure proiektuaren ezaugarriei buruz.
Teknologikoki, gure leialtasun sistemaren logikaren % 90 zerbitzarian oinarrituta dago eta Oracle-n inplementatuta dago. Bezero bat dago Delphi-n agerian, lantokiko administratzaile automatizatu baten funtzioa betetzen duena. Kanpoko aplikazioetarako (adibidez, webgune bat) web zerbitzuak agerian daude. Hori dela eta, oso logikoa da proba sistema automatizatu bat zabaltzen badugu, Oracle-n egingo dugula.
Sportmaster-en leialtasun sistemak 7 urte baino gehiago daramatza eta garatzaile bakarrek sortu zuten... Gure proiektuko garatzaileen batez besteko kopurua 7 urte hauetan 3-4 pertsona izan zen. Baina azken urtean, gure taldea nabarmen hazi da, eta orain 10 pertsona ari dira lanean proiektuan. Hau da, ohiko zereginak, prozesuak eta arkitektura ezagutzen ez dituen jendea etortzen da proiektura. Eta akatsak galtzeko arriskua areagotu egiten da.
Proiektuaren ezaugarria da langile-unitate gisa probatzaile dedikaturik ez egotea. Badago, noski, probak, baina probak analistek egiten dituzte, haien gainontzeko ardura nagusiez gain: negozio bezeroekin, erabiltzaileekin komunikatzea, sistemaren eskakizunak garatzea, etab. eta abar... Probak oso kalitate handikoak egiten diren arren (hau aipatzea bereziki egokia da, analista batzuek txosten honen begia har dezaketelako), espezializazioaren eta gauza batean kontzentratzeko eraginkortasuna ez da bertan behera utzi. .
Aurreko guztia kontuan hartuta, entregatutako produktuaren kalitatea hobetzeko eta garapen denbora murrizteko, proiektu batean probak automatizatzeko ideia oso logikoa dirudi. Eta leialtasun-sistemaren existentziaren fase desberdinetan, garatzaile indibidualak ahaleginak egin zituzten beren kodea unitate-testekin estaltzeko. Orokorrean nahiko prozesu deskonektua izan zen, bakoitzak bere arkitektura eta metodoak erabiliz. Azken emaitzak unitateko probetan ohikoak ziren: probak garatu ziren, denbora batez erabiliak, bertsiotutako fitxategien biltegiratze batean gordetzen ziren, baina noizbait exekutatzen gelditu ziren eta ahaztu egin ziren. Lehenik eta behin, probak interpretatzaile zehatz bati lotu zitzaizkiola gehiago, eta ez proiektuari.
utPLSQL erreskatatzera dator
Ba al dakizu ezer Stephen Feuersteini buruz?
Tipo adimentsu bat da, bere karreraren zati luze bat Oracle eta PL/SQL-ekin lan egitera eman zuena, eta gai honi buruzko lan ugari idatzi ditu. Bere liburu ospetsuetako bat deitzen da: βOracle PL/SQL. ProfesionalentzatΒ». Stephen izan zen utPLSQL irtenbidea garatu zuena, edo, esan nahi duen bezala, Oracle PL/SQLrako Unit Testing framework. utPLSQL irtenbidea 2016an sortu zen, baina aktiboki lantzen jarraitzen du eta bertsio berriak kaleratzen dira. Txostena emateko unean, azken bertsioa 24ko martxoaren 2019koa da.
Zer da hori. Hau kode irekiko proiektu bereizia da. Megabyte pare bat pisatzen ditu, adibideak eta dokumentazioa barne. Fisikoki, ORACLE datu-baseko eskema bereizia da, unitate-probak antolatzeko pakete eta taula multzo batekin. Instalazioak segundo batzuk behar ditu. utPLSQL-ren ezaugarri bereizgarri bat erabiltzeko erraztasuna da.
Orokorrean, utPLSQL unitate-probak exekutatzeko mekanismo bat da, non unitate-proba bat Oracle lote-prozedura arrunt gisa ulertzen den, eta horien antolaketak arau batzuk jarraitzen ditu. Abiarazteaz gain, utPLSQL-k zure proba-exekuzio guztien erregistroa gordetzen du, eta barneko txosten sistema bat ere badu.
Ikus dezagun teknika hau erabiliz inplementatutako unitate-test-kodearen itxuraren adibide bat.
Beraz, pantailak paketeen zehaztapen tipiko baten kodea erakusten du unitate-probekin. Zeintzuk dira derrigorrezko baldintzak? Paketeari "utp_" aurrizkia jarri behar zaio. Probak dituzten prozedura guztiek aurrizki bera izan behar dute. Paketeak bi prozedura estandar izan behar ditu: "utp_setup" eta "utp_teardown". Lehenengo prozedura unitate-test bakoitza berrabiaraziz deitzen da, bigarrena abiarazi ondoren.
"utp_setup", normalean, gure sistema unitate-proba bat exekutatzeko prestatzen du, adibidez, proba-datuak sortuz. "utp_teardown" - aitzitik, dena jatorrizko ezarpenetara itzultzen da eta abiarazteko emaitzak berrezartzen ditu.
Hona hemen sartutako bezeroaren telefono-zenbakiaren normalizazioa gure leialtasun-sistemarako inprimaki estandarra egiaztatzen duen unitate-test errazenaren adibide bat. Ez dago derrigorrezko estandarrik unitate-testekin prozedurak idazteko. Oro har, proban dagoen sistemaren metodo bati dei egiten zaio, eta metodo honek itzultzen duen emaitza erreferentziakoarekin alderatzen da. Garrantzitsua da erreferentziako emaitzaren eta lortutakoaren konparaketa utPLSQL metodo estandarren bidez egitea.
Unitate-proba batek edozein egiaztapen izan ditzake. Adibidean ikus daitekeenez, probatutako metodoari jarraian lau dei egiten dizkiogu telefono-zenbakia normalizatzeko eta dei bakoitzaren ondoren emaitza ebaluatzeko. Unitate-proba bat garatzerakoan, kontuan izan behar duzu sistemari inola ere eragiten ez dioten egiaztapenak daudela, eta zenbaiten ondoren sistemaren jatorrizko egoerara itzuli behar duzula.
Adibidez, aurkeztutako unitate-proban sarrerako telefono-zenbakia formateatu besterik ez dugu egiten, eta horrek ez dio inola ere leialtasun-sistemari eragiten.
Eta unitate-probak bezero berri bat sortzeko metodoa erabiliz idazten baditugu, proba bakoitzaren ondoren bezero berri bat sortuko da sisteman, eta horrek probaren ondorengo abiaraztean eragin dezake.
Honela exekutatzen dira unitate-probak. Bi abiarazte aukera daude: unitate-proba guztiak pakete zehatz batetik exekutatu edo unitate-proba zehatz bat pakete zehatz batean exekutatu.
Horrelakoa da barne-informazio-sistema baten adibidea. Unitate-probaren emaitzetan oinarrituta, utPLSQL-k txosten txiki bat eraikitzen du. Bertan egiaztapen zehatz bakoitzaren emaitza eta unitateko probaren emaitza orokorra ikusten dugu.
Autotesten 6 arau
Leialtasun-sistemaren proba automatikorako sistema berri bat sortzen hasi aurretik, kudeaketarekin batera, gure etorkizuneko proba automatizatuek bete behar dituzten printzipioak zehaztu genituen.
- Autotestek eraginkorrak eta erabilgarriak izan behar dute. Garatzaile zoragarriak ditugu, zalantzarik gabe aipatu beharrekoak, horietako batzuek ziurrenik txosten hau ikusiko dutelako eta kode zoragarria idazten dute. Baina haien kode zoragarria ere ez da perfektua eta akatsak ditu, ditu eta izango ditu. Autotestak beharrezkoak dira akats hauek aurkitzeko. Hori horrela ez bada, edo autotest txarrak idazten ari gara, edo printzipioz garatzen ez den eremu hil batera iritsi gara. Bi kasuetan, zerbait gaizki egiten ari gara, eta gure planteamenduak ez du zentzurik.
- Autotestak erabili behar dira. Ez du zentzurik denbora eta ahalegin asko gastatzea software-produktu bat idazten, biltegi batean sartu eta ahaztea. Probak egin behar dira, eta ahalik eta erregularren egin.
- Autotestek egonkor funtzionatu behar dute. Eguneko ordua, abiarazteko standa eta beste sistemaren ezarpenak edozein izanda ere, probak emaitza bera ekarri beharko lukete. Oro har, hori ziurtatzen da autotestek sistemaren ezarpen finkoekin probako datu bereziekin funtzionatzen dutelako.
- Autotestek zure proiekturako onargarria den abiaduran funtzionatu beharko lukete. Denbora hori sistema bakoitzerako banan-banan zehazten da. Batzuek egun osoan lan egitea ordaindu dezakete, eta beste batzuei segundotan egitea funtsezkoa iruditzen zaie. Geroxeago esango dizuet zein abiadura estandarrak lortu ditugun gure proiektuan.
- Autotestaren garapenak malgua izan behar du. Ez da komeni inolako funtzionalitate probatzeari uko egitea, aurretik egin ez dugulako edo beste arrazoiren bategatik. utPLSQL-k ez du inolako murrizketarik ezartzen garapenean, eta Oraclek, printzipioz, hainbat gauza inplementatzeko aukera ematen du. Arazo gehienek irtenbidea dute, denbora eta esfortzu kontua besterik ez da.
- Hedagarritasuna. Hainbat stand ditugu non probak egin behar ditugun. Stand bakoitzean, edozein unetan egunera daiteke datu-iraulketa bat. Beharrezkoa da proba automatikoekin proiektu bat egitea, bere instalazio osoa edo partziala onik gabe egin ahal izateko.
Eta pare bat egun barru bigarren postan zer egin dugun eta zer emaitza lortu ditugun kontatuko dizuet.
Iturria: www.habr.com