Unuaj provoj en DBMS - kiel ni faras ĝin en Sportmaster, dua parto

Unua parto - tie.

Imagu situacion. Vi alfrontas la taskon disvolvi novajn funkciojn. Vi havas sperton de viaj antaŭuloj. Supozante, ke vi ne havas moralajn devojn, kion vi farus?

Plej ofte, ĉiuj malnovaj evoluoj estas forgesitaj kaj ĉio rekomencas. Neniu ŝatas fosi la kodon de iu alia, kaj se vi havas tempon, kial ne komenci krei vian propran sistemon? Ĉi tio estas tipa aliro, kaj en multaj rilatoj ĝi estas ĝusta. Sed en nia projekto, ni agis alimaniere. Ni bazigis la estontan aŭtomatigitan testan sistemon sur la evoluoj en unuotestoj sur utPLSQL de niaj antaŭuloj, kaj poste eklaboris en pluraj paralelaj direktoj.

1. Restarigi malnovajn unutestojn. Reakiro signifas adapton de testoj al la ekzistanta stato de la lojalecsistemo kaj adapton de testoj al utPLSQL-normoj.
2. Solvante la problemon per kompreno, kaj kio ĝuste, kiaj metodoj kaj procezoj, ni kovris per aŭtotestoj. Vi devas aŭ konservi ĉi tiujn informojn en via kapo, aŭ eltiri konkludojn bazitajn rekte sur la kodo de aŭtotestoj. Tial ni decidis krei katalogon. Ni asignis unikan mnemonikan kodon al ĉiu aŭtotesto, kreis priskribon kaj riparis la agordojn (ekzemple, sub kiaj kondiĉoj ĝi devus esti rulita, aŭ kio devus okazi se la prova ekzekuto malsukcesas). Esence, ni plenigis la metadatenojn pri la aŭtotestoj kaj metis ĉi tiujn metadatenojn en la normajn tabelojn de la utPLSQL-skemo.
3. Difino de vastiga strategio, t.e. elekto de funkcieco kiu estas kondiĉigita de konfirmo per aŭtotestoj. Ni decidis atenti tri aferojn: novaj plibonigoj al la sistemo, okazaĵoj de produktado kaj ŝlosilaj procezoj de la sistemo. Tiel, ni evoluas paralele kun la liberigo, certigante ĝian pli altan kvaliton, samtempe vastigante la amplekson de la regreso kaj certigante la fidindecon de la sistemo en kritikaj lokoj. La unua tia proplemkolo estis la procezo de distribuado de rabatoj kaj gratifikoj per ĉeko.
4. Kompreneble, ni komencis evoluigi novajn aŭtotestojn. Unu el la unuaj eldontaskoj estis taksi la agadon de antaŭdifinitaj specimenoj de la lojalecsistemo. Nia projekto havas blokon de rigide fiksitaj sql-demandoj, kiuj elektas klientojn laŭ kondiĉoj. Ekzemple, ricevu liston de ĉiuj klientoj, kies lasta aĉeto estis en aparta urbo, aŭ liston de klientoj, kies averaĝa aĉetsumo estas super certa valoro. Skribinte aŭtotestojn, ni kontrolis antaŭdifinitajn specimenojn, fiksajn komparnormajn agado-parametrojn, kaj aldone ni ricevis ŝarĝtestadon.
5. Labori kun aŭtotestoj devus esti oportuna. La du plej oftaj agoj estas ruli aŭtotestojn kaj generi testajn datumojn. Tiel aperis en nia sistemo du helpaj moduloj: la lanĉa modulo kaj la datumgenerada modulo.

   La lanĉilo estas reprezentita kiel unu senmarka proceduro kun unu eniga tekstparametro. Kiel parametron, vi povas pasigi aŭtotestan mnemonikan kodon, pakaĵnomon, testnomon, aŭtotestan agordon aŭ rezervitan ŝlosilvorton. La proceduro elektas kaj ruligas ĉiujn aŭtotestojn, kiuj plenumas la kondiĉojn.

   La datumgenera modulo estas prezentita kiel pakaĵo, en kiu por ĉiu objekto de la testata sistemo (tabelo en la datumbazo), estas kreita speciala proceduro, kiu enmetas datumojn tie. En ĉi tiu proceduro, la defaŭltaj valoroj estas plenigitaj al la maksimumo, kio certigas la kreadon de objektoj laŭvorte per la klako de fingro. Kaj por facileco de uzo, ŝablonoj por la generitaj datumoj estis kreitaj. Ekzemple, kreu klienton de certa aĝo kun testa telefono kaj finita aĉeto.

6. Aŭtotestoj devus funkcii kaj funkcii en racia tempo por via sistemo. Tial, ĉiutage nokta lanĉo estis organizita, surbaze de kies rezultoj raporto pri la rezultoj estas generita kaj sendita al la tuta disvolva teamo per kompania poŝto. Post restarigo de malnovaj aŭtotestoj kaj kreado de novaj, la totala rultempo estis 30 minutoj. Tia agado konvenis al ĉiuj, ĉar la lanĉo okazis dum eksterhoroj.

   Sed ni devis labori por optimumigi la rapidecon de laboro. La produktadlojalecsistemo estas ĝisdatigita nokte. Kadre de unu el la eldonoj, ni devis urĝe fari ŝanĝojn nokte. Duonhoro atendado de la rezultoj de aŭtotestoj je la tria matene ne feliĉigis la respondeculon de la liberigo (ardaj salutoj al Aleksej Vasjukov!), Kaj la sekvan matenon oni diris multajn varmajn vortojn al nia sistemo. Sed kiel rezulto, 5-minuta normo por laboro estis starigita.

   Por akceli agadon, ni uzis du metodojn: ni komencis ruli aŭtotestojn en tri paralelaj fadenoj, ĉar tio estas tre oportuna pro la arkitekturo de nia lojaleca sistemo. Kaj ni forlasis la aliron kiam la aŭtotesto ne kreas testajn datumojn por si mem, sed provas trovi ion taŭgan en la sistemo. Post fari ŝanĝojn, la totala operacia tempo estis reduktita al 3-4 minutoj.

7. Projekto kun aŭtotestoj devus povi esti deplojita sur diversaj standoj. Komence de la vojaĝo, estis provoj skribi niajn proprajn batajn dosierojn, sed evidentiĝis, ke memskribita aŭtomatigita instalaĵo estas kompleta teruro, kaj ni turnis nin al industriaj solvoj. Pro la fakto, ke la projekto havas multe da kodo rekte (antaŭ ĉio, ni stokas la kodon de aŭtotestoj) kaj tre malmulte da datumoj (la ĉefaj datumoj estas metadatenoj pri aŭtotestoj), ĝi montriĝis tre facile integrebla en la Projekto Liquibase.

   Ĝi estas malfermfonta datumbaza sendependa biblioteko por spuri, administri kaj apliki datumbazajn skemŝanĝojn. Administrita per komandlinio aŭ kadroj kiel Apache Maven. La principo de funkciado de Liquibase estas sufiĉe simpla. Ni havas projekton organizitan laŭ certa maniero, kiu konsistas el ŝanĝoj aŭ skriptoj, kiuj devas esti rulitaj sur la celservilon, kaj kontrolaj dosieroj, kiuj determinas en kia ordo kaj kun kiaj parametroj ĉi tiuj ŝanĝoj devus esti instalitaj.

   Je la DBMS-nivelo, speciala tabelo estas kreita, en kiu Liquibase konservas la protokolon de malfunkciigo. Ĉiu ŝanĝo havas kalkulitan haŝon, kiu estas komparata ĉiufoje inter la projekto kaj la stato en la datumbazo. Danke al Liquibase, ni povas facile efektivigi ŝanĝojn al nia sistemo al iu ajn cirkvito. Aŭtotestoj nun estas rulitaj sur provaj kaj eldonbukloj, same kiel sur ujoj (personaj bukloj de programistoj).

Do, ni parolu pri la rezultoj de aplikado de nia unutesta sistemo.

1. Kompreneble, antaŭ ĉio, ni estas konvinkitaj, ke ni komencis disvolvi pli bonan programaron. Aŭtotestoj funkcias ĉiutage kaj trovas dekojn da cimoj ĉiu eldono. Krome, iuj el ĉi tiuj eraroj nur nerekte rilatas al la funkcio, kiun ni vere volis ŝanĝi. Estas fortaj duboj, ke ĉi tiuj eraroj estis trovitaj per manaj provoj.
2. La teamo akiris konfidon, ke specifa funkcio funkcias ĝuste... Antaŭ ĉio, ĉi tio koncernas niajn kritikajn procezojn. Ekzemple, dum la pasintaj ses monatoj, ni havis neniujn problemojn kun la distribuado de rabatoj kaj gratifikoj per ĉeko, malgraŭ la ŝanĝoj faritaj ĉiu eldono, kvankam en antaŭaj periodoj eraroj okazis kun ioma ofteco.
3. Ni sukcesis redukti la nombron da provaj ripetoj. Pro la fakto, ke aŭtotestoj estas verkitaj por novaj funkcioj, analizistoj kaj partatempaj testistoj ricevas kodon de pli alta kvalito, ĉar ĝi jam estis kontrolita.
4. Parto de la evoluoj de aŭtomata testado estas uzata de programistoj. Ekzemple, testaj datumoj pri ujoj estas kreitaj per la objekta genera modulo.
5. Gravas, ke ni evoluigis "akcepton" de la aŭtomata testa sistemo de programistoj. Estas kompreno, ke ĉi tio estas grava kaj utila. Kaj laŭ mia propra sperto, mi povas diri, ke ĉi tio estas malproksime de la kazo. Aŭtotestoj devas esti skribitaj, ili devas esti konservitaj kaj disvolvitaj, la rezultoj analizitaj, kaj ofte ĉi tiuj tempokostoj simple ne valoras ĝin. Estas multe pli facile iri al produktado kaj trakti problemojn tie. En nia lando, programistoj viciĝas kaj petas kovri sian funkciecon per aŭtotestoj.

Kio sekvas

Ni parolu pri la disvolvaj planoj de la aŭtomata testa projekto.

Kompreneble, dum la sistemo de lojaleco Sportmaster estas viva kaj daŭre disvolviĝas, aŭtotestoj ankaŭ povas esti disvolvitaj preskaŭ senfine. Tial, la ĉefa direkto de disvolviĝo estas la vastiĝo de la kovra areo.

Ĉar la nombro da aŭtotestoj pliiĝas, la tuta tempo de ilia laboro konstante pliiĝos, kaj ni denove devos reveni al la afero de rendimento. Plej verŝajne, la solvo estos pliigi la nombron da paralelaj fadenoj.

Sed ĉi tiuj estas evidentaj manieroj de evoluo. Se ni parolas pri io pli ne-triviala, ni reliefigas la jenajn:

1. Nun aŭtotestoj estas administritaj ĉe la DBMS-nivelo, t.e. scio pri PL/SQL estas postulata por sukcesa laboro. Se necese, sistemadministrado (ekzemple, lanĉo aŭ kreado de metadatenoj) povas esti elprenita de ia administra panelo uzante Jenkins aŭ ion similan.
2. Ĉiuj amas kvantajn kaj kvalitajn indikilojn. Por aŭtomata testado, tia universala indikilo estas Koda Priraportado aŭ koda priraporta metriko. Uzante ĉi tiun indikilon, ni povas determini kian procenton de la kodo de nia sistemo sub testo estas kovrita de aŭtotestoj. Komencante de versio 12.2, Oracle disponigas la kapablon kalkuli ĉi tiun metrikon kaj sugestas uzi la norman DBMS_PLSQL_CODE_COVERAGE-pakaĵon.

   Nia aŭtotesta sistemo aĝas iom pli ol unu jaron kaj eble estas tempo por taksi kovradon. En mia lasta projekto (projekto ne de Sportmaster), tio okazis. Jaron post laborado pri aŭtotestoj, la administrado fiksis la taskon taksi kian procenton de la kodo ni kovris. Kun pli ol 1% kovrado, administrado estus feliĉa. Ni, la programistoj, atendis rezulton de ĉirkaŭ 10%. Ni fuŝis kodan kovradon, mezuris ĝin, ricevis 20%. Por festi, ni iris por la premio, sed kiel ni iris por ĝi kaj kien ni iris poste estas tute alia rakonto.

3. Aŭtotestoj povas testi elmontritajn retservojn. Oracle permesas al vi fari tion, kaj ni ne plu renkontos kelkajn problemojn.
4. Kaj, kompreneble, nia aŭtomata testa sistemo povas esti aplikita al alia projekto. La solvo, kiun ni ricevis, estas universala kaj nur postulas la uzon de Oracle. Mi aŭdis, ke estas intereso pri aŭtomatigita testado pri aliaj Sportmaster-projektoj kaj, eble, ni iros al ili.

trovoj

Ni resumu. En la projekto pri lojaleca sistemo en Sportmaster, ni sukcesis efektivigi aŭtomatan testan sistemon. Ĝia bazo estas la utPLSQL-solvo de Stephen Feuerstein. Ĉirkaŭ utPLSQL estas la kodo por aŭtotestoj kaj helpaj memskribitaj moduloj: lanĉilo, datumgenera modulo kaj aliaj. Aŭtotestoj funkcias ĉiutage kaj, plej grave, funkcias kaj profitas. Ni estas konvinkitaj, ke ni komencis eldoni programaron de pli alta kvalito. Samtempe, la rezulta solvo estas universala kaj povas esti libere aplikata al iu ajn projekto, kie necesas organizi aŭtomatajn provojn pri Oracle DBMS.

PS Ĉi tiu artikolo montriĝis ne tre specifa: estas multe da teksto kaj preskaŭ neniuj teknikaj ekzemploj. Se la temo estas tutmonde interesa, tiam ni pretas daŭrigi ĝin kaj reveni kun daŭrigo, kie ni rakontos al vi, kio ŝanĝiĝis dum la pasintaj ses monatoj kaj donos kodajn ekzemplojn.

Skribu komentojn se estas punktoj kiuj devus esti emfazitaj en la estonteco, aŭ demandoj kiuj postulas malkaŝon.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Ĉu ni skribu pli pri tio?

• Ho certe

• Ne, dankon

Voĉdonis 12 uzantoj. 4 uzantoj sindetenis.

fonto: www.habr.com