Unitate-probak DBMS batean - nola egiten dugun Sportmaster-en, bigarren zatia

Lehen zatia - Hemen.

Imajinatu egoera bat. Funtzio berriak garatzeko zereginaren aurrean zaude. Zure aurrekoen esperientzia duzu. Betebehar moralik ez duzula suposatuz, zer egingo zenuke?

Gehienetan, garapen zahar guztiak ahaztu egiten dira eta dena berriro hasten da. Inori ez zaio gustatzen beste inoren kodean sakontzea, eta denbora baduzu, zergatik ez hasi zure sistema propioa sortzen? Hau planteamendu tipikoa da, eta zentzu askotan zuzena da. Baina gure proiektuan beste era batera jokatu genuen. Etorkizuneko proba automatizatuko sistema gure aurrekoen utPLSQL-n egindako unitate-probetan izandako garapenetan oinarritu genuen, eta, ondoren, hainbat norabide paralelotan lan egin genuen.

1. Unitate-proba zaharrak berreskuratzea. Berreskuratzeak esan nahi du probak leialtasun sistemaren egoerara egokitzea eta probak utPLSQL estandarretara egokitzea.
2. Arazoa ulermenarekin konpontzea, eta zehazki zer, zer metodo eta prozesu, autotestekin estali dugu. Informazio hori buruan gorde behar duzu, edo autotesten kodean zuzenean oinarritutako ondorioak atera behar dituzu. Horregatik, katalogo bat sortzea erabaki genuen. Autotest bakoitzari kode mnemotekniko esklusibo bat esleitu genion, deskribapen bat sortu eta ezarpenak konpondu genituen (adibidez, zein baldintzatan exekutatu behar den edo zer gertatu behar den probak huts egiten badu). Funtsean, autotestei buruzko metadatuak bete ditugu eta metadatu hauek utPLSQL eskemaren taula estandarretan kokatu ditugu.
3. Hedapen estrategiaren definizioa, hau da. Autotesten bidez egiaztatzeko gai diren funtzionalitateak hautatzea. Hiru gauzari erreparatzea erabaki genuen: sistemaren hobekuntza berriak, ekoizpenaren gorabeherak eta sistemaren funtsezko prozesuei. Horrela, kaleratzearekin batera garatzen dugu, bere kalitate handiagoa bermatuz, aldi berean erregresioaren esparrua zabalduz eta sistemaren fidagarritasuna leku kritikoetan bermatuz. Horrelako lehen botilak txeke bidez deskontuak eta hobariak banatzeko prozesua izan zen.
4. Berez, autotest berriak garatzen hasi ginen. Lehen kaleratze-zereginetako bat leialtasun-sistemaren aurredefinitutako laginen errendimendua ebaluatzea izan zen. Gure proiektuak zurrun finkatutako sql kontsulta bloke bat du, bezeroak baldintzen arabera hautatzen dituena. Adibidez, lortu azken erosketa hiri jakin batean izan duten bezero guztien zerrenda edo batez besteko erosketa-kopurua balio jakin batetik gorakoa duten bezeroen zerrenda. Autotestak idatzita, aurrez zehaztutako laginak, erreferentziazko errendimendu-parametro finkoak egiaztatu ditugu eta, gainera, karga-probak egin ditugu.
5. Autotestekin lan egitea komenigarria izan behar da. Bi ekintza ohikoenak autotestak egitea eta proba datuak sortzea dira. Horrela agertu ziren gure sisteman bi modulu laguntzaile: abiarazte-modulua eta datuak sortzeko modulua.

   Abiarazlea prozedura generiko gisa adierazten da sarrerako testu-parametro batekin. Parametro gisa, autotest kode mnemoteknikoa, paketearen izena, probaren izena, autotest ezarpena edo erreserbatutako gako-hitz bat pasa ditzakezu. Prozedurak baldintzak betetzen dituzten autotest guztiak hautatu eta exekutatzen ditu.

   Datuak sortzeko modulua pakete gisa aurkezten da, eta bertan probatzen ari den sistemaren objektu bakoitzeko (taula bat datu-basean), prozedura berezi bat sortu da, bertan datuak txertatzen dituena. Prozedura honetan, balio lehenetsiak gehienez betetzen dira, eta horrek bermatzen du objektuak literalki hatz klik eginez. Eta erabiltzeko erraztasunerako, sortutako datuetarako txantiloiak sortu ziren. Adibidez, sortu adin jakin bateko bezero bat probako telefono batekin eta erosketa osatu batekin.

6. Autotestak zure sistemarako arrazoizko epe batean exekutatu eta exekutatu behar dira. Hori dela eta, egunero gaueko abian jartzea antolatu zen, eta horren emaitzen arabera emaitzen txostena sortzen da eta garapen talde osoari posta korporatibo bidez bidaltzen zaio. Autotest zaharrak berreskuratu eta berriak sortu ondoren, exekuzio-denbora osoa 30 minutukoa izan zen. Emanaldi hori guztioi egokitu zitzaion, kaleratzea orduz kanpo egin baitzen.

   Baina lanaren abiadura optimizatzeko lan egin behar izan genuen. Produkzioaren fidelizazio sistema gauez eguneratzen da. Argitalpenetako baten baitan, premiazko aldaketak egin behar izan genituen gauez. Goizeko hiruretan autotesten emaitzen zain ordu erdi batek ez zuen askapenaren arduraduna poztu (agur sutsua Alexei Vasyukov-i!), eta hurrengo goizean hitz bero asko esan ziren gure sistemari buruz. Baina, ondorioz, lanerako 5 minutuko estandarra ezarri zen.

   Errendimendua bizkortzeko, bi metodo erabili ditugu: autotestak hiru hari paralelotan exekutatzen hasi ginen, hau oso erosoa baita gure leialtasun sistemaren arkitekturagatik. Eta planteamendua alde batera utzi genuen autotestak ez dituenean proba-daturik sortzen, sisteman zerbait egokia bilatzen saiatzen denean. Aldaketak egin ondoren, operazio-denbora 3-4 minutura murriztu zen.

7. Autotestak dituen proiektu batek hainbat standetan zabaldu ahal izan behar du. Bidaiaren hasieran, gure batch fitxategiak idazteko saiakerak egon ziren, baina argi geratu zen norberak idatzitako instalazio automatizatu bat izugarrikeria bat dela, eta irtenbide industrialetara jo genuen. Proiektuak zuzenean kode asko dituelako (lehenik, autotesten kodea gordetzen dugu) eta oso datu gutxi (datu nagusiak autotestei buruzko metadatuak dira), oso erraza izan da integratzea. Liquibase proiektua.

   Kode irekiko datu-baseen liburutegi independentea da, datu-baseen eskema-aldaketak jarraitzeko, kudeatzeko eta aplikatzeko. Komando lerro edo Apache Maven bezalako esparruen bidez kudeatzen da. Liquibase-ren funtzionamendu-printzipioa nahiko erraza da. Modu jakin batean antolatutako proiektu bat dugu, helburuko zerbitzarian txertatu beharreko aldaketak edo scriptek osatzen dutena, eta aldaketa horiek zein ordenatan eta zer parametrorekin instalatu behar diren zehazten duten kontrol-fitxategiak.

   DBMS mailan, taula berezi bat sortzen da eta bertan Liquibase-k desegiteko erregistroa gordetzen du. Aldaketa bakoitzak hash kalkulatu bat du, proiektuaren eta datu-baseko egoeraren artean konparatzen den bakoitzean. Liquibaseri esker, gure sisteman aldaketak erraz egin ditzakegu edozein zirkuitutan. Autotestak proba eta kaleratzeko begiztetan exekutatzen dira, baita edukiontzietan ere (garatzaileen begizta pertsonalak).

Beraz, hitz egin dezagun gure unitate-proba sistema aplikatzearen emaitzei buruz.

1. Noski, lehenik eta behin, software hobea garatzen hasi ginela sinetsita gaude. Autotestak egunero egiten dira eta dozenaka akats aurkitzen dituzte bertsio bakoitzean. Gainera, akats horietako batzuk benetan aldatu nahi genuen funtzionaltasunarekin zeharka bakarrik daude lotuta. Zalantza handiak daude akats horiek eskuzko probetan aurkitu zirela.
2. Taldeak konfiantza hartu zuen funtzionaltasun zehatzak behar bezala funtzionatzen duela... Lehenik eta behin, gure prozesu kritikoei dagokie. Esaterako, azken sei hilabeteotan, ez dugu arazorik izan deskontuak eta hobariak txeke bidez banatzeko, kaleratze guztietan aldaketak egin arren, nahiz eta aurreko aldietan akatsak maiztasun batekin gertatu.
3. Proba-iterazioen kopurua murriztea lortu dugu. Autotestak funtzionalitate berrietarako idazten direnez, analistek eta lanaldi partzialeko probatzaileek kalitate handiagoko kodea lortzen dute, izan ere dagoeneko egiaztatu da.
4. Proba automatizatuen garapenen zati bat garatzaileek erabiltzen dute. Adibidez, edukiontziei buruzko proba-datuak objektuak sortzeko modulua erabiliz sortzen dira.
5. Garrantzitsua da garatzaileek proba automatikoen sistemaren "onarpena" garatu izana. Hau garrantzitsua eta erabilgarria dela ulertzen da. Eta nire esperientziatik, esan dezaket hori urrun dagoela. Autotestak idatzi behar dira, mantendu eta garatu behar dira, emaitzak aztertu, eta askotan denbora-kostu horiek ez dute merezi. Askoz errazagoa da ekoizpenera joatea eta bertan arazoei aurre egitea. Gure herrialdean, garatzaileek lerroa jartzen dute eta beren funtzionalitatea autotestekin estaltzeko eskatzen dute.

Zer da hurrengoa

Hitz egin dezagun proba automatikoen proiektuaren garapen planei buruz.

Jakina, Sportmaster leialtasun sistema bizirik dagoen bitartean eta garatzen jarraitzen duen bitartean, autotestak ere ia amaigabe garatu daitezke. Hori dela eta, garapenaren ildo nagusia estaldura-eremua zabaltzea da.

Autotesten kopurua handitzen den heinean, haien lanaren denbora osoa etengabe handituko da, eta berriro ere errendimenduaren gaira itzuli beharko dugu. Seguruenik, irtenbidea hari paraleloen kopurua handitzea izango da.

Baina horiek garatzeko modu agerikoak dira. Zerbait ez-hutsez hitz egiten badugu, honako hauek nabarmenduko ditugu:

1. Orain autotestak DBMS mailan kudeatzen dira, hau da. PL/SQL ezagutza beharrezkoa da lan arrakastatsua izateko. Beharrezkoa izanez gero, sistemaren kudeaketa (adibidez, metadatuak abiarazi edo sortzea) administrazio-panel motaren baten bidez atera daiteke Jenkins edo antzeko zerbait erabiliz.
2. Denek maite dituzte adierazle kuantitatiboak eta kualitatiboak. Proba automatikoetarako, adierazle unibertsala Kode-estaldura edo kode-estalduraren metrika da. Adierazle hau erabiliz, autotestek probatzen duten gure sistemaren kodearen zein ehunekotan estaltzen duten zehaztu dezakegu. 12.2 bertsiotik hasita, Oracle-k metrika hau kalkulatzeko gaitasuna eskaintzen du eta DBMS_PLSQL_CODE_COVERAGE pakete estandarra erabiltzea proposatzen du.

   Gure autotest sistemak urtebete pasatxo du eta baliteke estaldura ebaluatzeko garaia izatea. Nire azken proiektuan (Sportmasterrena ez den proiektua), hau gertatu zen. Autotestetan lan egin eta urtebetera, zuzendaritzak ezarri zuen kodearen zein ehunekotan estali genuen ebaluatzeko zeregina. %1 baino gehiagoko estaldurarekin, zuzendaritza pozik egongo litzateke. Garatzaileek %10 inguruko emaitza espero genuen. Kode estaldura izorratu dugu, neurtu, %20 lortu dugu. Ospatzeko, sari bila joan ginen, baina nola joan ginen eta gero nora joan ginen guztiz bestelakoa da.

3. Autotestek agerian dauden web zerbitzuak proba ditzakete. Oraclek hau egiteko aukera ematen dizu, eta jada ez dugu arazo ugari topatuko.
4. Eta, noski, gure proba automatikoko sistema beste proiektu batean aplika daiteke. Jaso dugun irtenbidea unibertsala da eta Oracle erabiltzea baino ez da behar. Entzun nuen beste Sportmaster proiektuetan proba automatizatuetarako interesa dagoela eta, agian, horietara joango gara.

Findings

Errepasatu dezagun. Sportmaster-en leialtasun sistemaren proiektuan, proba sistema automatizatu bat ezartzea lortu genuen. Bere oinarria Stephen Feuerstein-en utPLSQL irtenbidea da. Inguruan utPLSQL autotestetarako eta auto-idatzitako modulu osagarrietarako kodea dago: abiarazlea, datuak sortzeko modulua eta beste batzuk. Autotestak egunero exekutatzen dira eta, batez ere, lan egiten dute eta etekina dute. Sinetsita gaude kalitate handiagoko softwarea kaleratzen hasi garela. Aldi berean, lortzen den irtenbidea unibertsala da eta libreki aplika daiteke Oracle DBMSan proba automatikoak antolatzea beharrezkoa den edozein proiektutan.

PS Artikulu hau ez da oso zehatza izan: testu asko dago eta ia adibide teknikorik ez dago. Gaia orokorrean interesgarria bada, orduan jarraitu eta jarraipen batekin itzultzeko prest gaude, non azken sei hilabeteetan zer aldatu den kontatuko dizugu eta kodeen adibideak emango ditugu.

Idatzi iruzkinak etorkizunean azpimarratu beharreko puntuak badaude, edo ezagutaraztea eskatzen duten galderak.

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Gehiago idatziko al dugu honi buruz?

• Bai, jakina

• Ez eskerrik asko

12 erabiltzailek eman dute botoa. 4 erabiltzaile abstenitu ziren.

Iturria: www.habr.com