Einingapróf í DBMS - hvernig við gerum það í Sportmaster, fyrsta hluta

Hæ Habr!

Ég heiti Maxim Ponomarenko og er þróunaraðili hjá Sportmaster. Ég hef 10 ára reynslu á upplýsingatæknisviðinu. Hann hóf feril sinn í handvirkum prófunum og skipti síðan yfir í gagnagrunnsþróun. Undanfarin 4 ár hef ég safnað þeirri þekkingu sem ég fékk í prófun og þróun, sjálfvirkt prófun á DBMS stigi.

Ég hef verið í Sportmaster teyminu í rúmt ár og er að þróa sjálfvirkar prófanir á einu af helstu verkefnum. Í apríl töluðum við strákarnir frá Sportmaster Lab á ráðstefnu í Krasnodar, skýrslan mín var kölluð „Einingapróf í DBMS,“ og nú vil ég deila henni með ykkur. Það verður mikill texti svo ég ákvað að skipta skýrslunni í tvær færslur. Í fyrsta lagi munum við tala um sjálfvirkar prófanir og prófanir almennt, og í þeim seinni mun ég dvelja nánar á einingarprófunarkerfinu okkar og niðurstöðum beitingar þess.

Í fyrsta lagi smá leiðinleg kenning. Hvað er sjálfvirk prófun? Þetta eru prófanir sem eru gerðar með hugbúnaði og í nútíma upplýsingatækni er það í auknum mæli notað í hugbúnaðarþróun. Þetta er vegna þess að fyrirtæki eru að stækka, upplýsingakerfi þeirra eru að stækka og því eykst magn virkni sem þarf að prófa. Að framkvæma handvirkar prófanir er að verða dýrari og dýrari.

Ég vann hjá stóru fyrirtæki sem kemur út á tveggja mánaða fresti. Á sama tíma fór heill mánuður í að láta tugi prófara handvirkt athuga virknina. Þökk sé innleiðingu sjálfvirkni af litlu teymi þróunaraðila tókst okkur að stytta prófunartímann í 2 vikur á einu og hálfu ári. Við höfum ekki aðeins aukið hraða prófana heldur einnig bætt gæði þess. Sjálfvirk próf eru sett af stað reglulega og þau framkvæma alltaf allt eftirlitið sem er innifalið í þeim, það er að segja að við útilokum mannlega þáttinn.

Nútíma upplýsingatækni einkennist af því að verktaki gæti þurft að skrifa ekki aðeins vörukóða, heldur einnig að skrifa einingapróf sem athuga þennan kóða.

En hvað ef kerfið þitt byggist fyrst og fremst á rökfræði miðlara? Það er engin alhliða lausn eða bestu starfsvenjur á markaðnum. Að jafnaði leysa fyrirtæki þetta vandamál með því að búa til sitt eigið sjálfskrifaða prófunarkerfi. Þetta er okkar eigin sjálfskrifaða sjálfvirka prófunarkerfi sem var búið til í verkefninu okkar og ég mun tala um það í skýrslu minni.

Reynir á hollustu

Í fyrsta lagi skulum við tala um verkefnið þar sem við settum upp sjálfvirkt prófunarkerfi. Verkefnið okkar er Sportmaster tryggðarkerfið (við the vegur, við höfum þegar skrifað um það í þessa færslu).

Ef fyrirtækið þitt er nógu stórt, þá mun tryggðarkerfið þitt hafa þrjá staðlaða eiginleika:

• Kerfið þitt verður mikið hlaðið
• Kerfið þitt mun innihalda flókin tölvuferli
• Kerfið þitt verður virkt endurbætt.

Við skulum fara í röð... Alls, ef við skoðum öll Sportmaster vörumerki, þá erum við með meira en 1000 verslanir í Rússlandi, Úkraínu, Kína, Kasakstan og Hvíta-Rússlandi. Um 300 innkaup fara fram í þessum verslunum á hverjum degi. Það er, 000-3 ávísanir á sekúndu fresti fara inn í kerfið okkar. Vildarkerfi okkar er náttúrulega mjög hlaðið. Og þar sem það er virkt notað, verðum við að veita ströngustu gæðastaðla þess, vegna þess að allar villur í hugbúnaðinum þýðir mikið peningalegt, orðspor og annað tap.

Á sama tíma rekur Sportmaster meira en hundrað mismunandi kynningar. Það eru margvíslegar kynningar: það eru vörukynningar, það eru þær sem eru tileinkaðar vikudegi, það eru þær sem eru bundnar við tiltekna verslun, það eru kynningar fyrir upphæð kvittunar, það eru fyrir fjölda vöru. Almennt séð ekki slæmt. Viðskiptavinir hafa bónusa og kynningarkóða sem eru notaðir við kaup. Allt þetta leiðir til þess að útreikningur á hvaða röð sem er er mjög ekki léttvægt verkefni.

Reikniritið sem útfærir pöntunarvinnslu er sannarlega hræðilegt og flókið. Og allar breytingar á þessu reikniriti eru mjög áhættusamar. Svo virtist sem óverulegustu breytingarnar gætu leitt til nokkuð ófyrirsjáanlegra áhrifa. En það eru einmitt svo flókin tölvuferli, sérstaklega þau sem innleiða mikilvæga virkni, sem eru bestir möguleikarnir fyrir sjálfvirkni. Það er mjög tímafrekt að athuga tugi svipaðra mála með höndunum. Og þar sem inngangspunkturinn í ferlið er óbreyttur, eftir að hafa lýst því einu sinni, geturðu fljótt búið til sjálfvirk próf og verið viss um að virknin muni virka.

Þar sem kerfið okkar er virkt notað, mun fyrirtækið vilja fá eitthvað nýtt frá þér, lifa með tímanum og vera viðskiptavinamiðað. Í vildarkerfi okkar koma útgáfur út á tveggja mánaða fresti. Þetta þýðir að á tveggja mánaða fresti þurfum við að framkvæma algjöra afturför á öllu kerfinu. Á sama tíma, náttúrulega, eins og í öllum nútíma upplýsingatækni, fer þróunin ekki strax frá verktaki til framleiðslu. Það á uppruna sinn í hringrás þróunaraðilans, fer síðan í röð í gegnum prófunarbekkinn, losun, samþykki og endar síðan í framleiðslu. Að minnsta kosti, á prófunar- og losunarrásum, þurfum við að framkvæma algjöra afturför á öllu kerfinu.

Eignirnar sem lýst er eru staðlaðar fyrir nánast hvaða tryggðarkerfi sem er. Við skulum tala um eiginleika verkefnisins okkar.

Tæknilega séð er 90% af rökfræði tryggðarkerfisins okkar byggt á netþjónum og innleitt á Oracle. Það er viðskiptavinur afhjúpaður í Delphi, sem sinnir hlutverki sjálfvirks vinnustaðastjórnanda. Það eru óvarðar vefþjónustur fyrir utanaðkomandi forrit (til dæmis vefsíðu). Þess vegna er mjög rökrétt að ef við setjum upp sjálfvirkt prófunarkerfi munum við gera það á Oracle.

Vildarkerfið í Sportmaster hefur verið til í meira en 7 ár og var búið til af einstökum forriturum... Meðalfjöldi þróunaraðila á verkefninu okkar á þessum 7 árum var 3-4 manns. En á síðasta ári hefur teymi okkar stækkað verulega og nú eru 10 manns að vinna að verkefninu. Það er að segja að fólk kemur að verkefninu sem þekkir ekki dæmigerð verkefni, ferla og arkitektúr. Og það er aukin hætta á að við missum af mistökum.

Verkefnið einkennist af fjarveru sérstakra prófana sem starfsmannaeiningar. Það eru að sjálfsögðu prófun, en prófun er framkvæmd af greiningaraðilum, auk annarra meginskyldna þeirra: samskipti við viðskiptavini, notendur, þróa kerfiskröfur o.s.frv. o.s.frv... Þrátt fyrir að prófanir séu gerðar mjög vönduð (þetta er sérstaklega viðeigandi að minnast á, þar sem sumir sérfræðingarnir gætu vakið athygli þessarar skýrslu), hefur árangur sérhæfingar og einbeitingar á eitt atriði ekki verið hætt. .

Miðað við allt ofangreint, til að bæta gæði afhentrar vöru og draga úr þróunartíma, virðist hugmyndin um að gera sjálfvirk prófun á verkefni mjög rökrétt. Og á mismunandi stigum tilveru vildarkerfisins lögðu einstakir verktaki tilraunir til að ná yfir kóðann sinn með einingaprófum. Á heildina litið var þetta frekar sundurleitt ferli, þar sem allir notuðu sinn eigin arkitektúr og aðferðir. Lokaniðurstöður voru sameiginlegar fyrir einingapróf: próf voru þróuð, notuð í nokkurn tíma, geymd í útgefnum skráargeymslu, en á einhverjum tímapunkti hættu þau að keyra og gleymdist. Í fyrsta lagi var þetta vegna þess að prófin voru meira bundin við ákveðinn flytjanda, en ekki við verkefnið.

utPLSQL kemur til bjargar

Veistu eitthvað um Stephen Feuerstein?

Þetta er klár strákur sem helgaði langan hluta ferils síns að vinna með Oracle og PL/SQL og hefur skrifað töluvert af verkum um þetta efni. Ein af frægu bókunum hans heitir: „Oracle PL/SQL. Fyrir fagfólk." Það var Stephen sem þróaði utPLSQL lausnina, eða eins og hún stendur fyrir Unit Testing framework fyrir Oracle PL/SQL. UtPLSQL lausnin var búin til árið 2016, en áfram er unnið að henni og nýjar útgáfur eru gefnar út. Við skýrslutöku er nýjasta útgáfan aftur til 24. mars 2019.
Hvað er það. Þetta er sérstakt opinn uppspretta verkefni. Það vegur nokkur megabæt, þar á meðal dæmi og skjöl. Líkamlega er það sérstakt skema í ORACLE gagnagrunninum með setti af pökkum og töflum til að skipuleggja einingapróf. Uppsetning tekur nokkrar sekúndur. Sérkenni utPLSQL er auðvelt í notkun.
Á heimsvísu er utPLSQL vélbúnaður til að keyra einingapróf, þar sem einingapróf er skilið sem venjulegar Oracle lotuaðferðir, en skipulag þeirra fylgir ákveðnum reglum. Auk þess að ræsa, geymir utPLSQL skrá yfir allar prófanir þínar og hefur einnig innra skýrslukerfi.

Við skulum skoða dæmi um hvernig einingaprófskóðinn lítur út, útfærður með þessari tækni.

Svo, skjárinn sýnir kóðann fyrir dæmigerða pakkaforskrift með einingaprófum. Hverjar eru lögboðnar kröfur? Forskeyti pakkans verður að vera „utp_“. Allar aðferðir með prófum verða að hafa nákvæmlega sama forskeyti. Pakkinn verður að innihalda tvær staðlaðar verklagsreglur: „utp_setup“ og „utp_teardown“. Fyrsta aðferðin er kölluð með því að endurræsa hvert einingapróf, annað - eftir sjósetja.

„utp_setup“ undirbýr að jafnaði kerfið okkar til að keyra einingapróf, til dæmis að búa til prófunargögn. "utp_teardown" - þvert á móti, allt fer aftur í upprunalegu stillingarnar og endurstillir ræsingarniðurstöðurnar.

Hér er dæmi um einfaldasta einingaprófið sem athugar eðlilega staðlaða símanúmer viðskiptavinarins á staðlaða eyðublaðið fyrir vildarkerfi okkar. Það eru engir lögboðnir staðlar um hvernig eigi að skrifa verklag með einingaprófum. Að jafnaði er hringt í aðferð kerfisins sem verið er að prófa og niðurstaðan sem þessi aðferð skilar borin saman við viðmiðunaraðferðina. Það er mikilvægt að samanburður á viðmiðunarniðurstöðunni og þeirri sem fæst sé með stöðluðum utPLSQL aðferðum.

Einingapróf getur haft hvaða fjölda athugana sem er. Eins og sést á dæminu hringjum við fjögur símtöl í röð í prófuðu aðferðina til að staðla símanúmerið og meta niðurstöðuna eftir hvert símtal. Þegar þú þróar einingapróf verður þú að taka með í reikninginn að það eru athuganir sem hafa ekki áhrif á kerfið á nokkurn hátt og eftir nokkurn tíma þarftu að fara aftur í upprunalegt ástand kerfisins.
Til dæmis, í kynntu einingaprófinu forsníðum við einfaldlega inntakssímanúmerið, sem hefur ekki áhrif á vildarkerfið á nokkurn hátt.

Og ef við skrifum einingapróf með því að búa til nýjan viðskiptavin, þá verður nýr viðskiptavinur búinn til í kerfinu eftir hverja prófun, sem getur haft áhrif á síðari ræsingu prófsins.

Svona eru einingapróf keyrð. Það eru tveir mögulegir ræsingarvalkostir: keyra öll einingapróf úr tilteknum pakka eða keyra tiltekið einingapróf í tilteknum pakka.

Svona lítur dæmi um innra skýrslukerfi út. Byggt á niðurstöðum einingaprófsins, byggir utPLSQL litla skýrslu. Í henni sjáum við niðurstöðuna fyrir hverja tiltekna athugun og heildarniðurstöðu einingarprófsins.

6 reglur um sjálfvirkar prófanir

Áður en byrjað var að búa til nýtt kerfi fyrir sjálfvirkar prófanir á vildarkerfinu ákváðum við ásamt stjórnendum hvaða meginreglur framtíðar sjálfvirk próf okkar ættu að uppfylla.

1. Sjálfvirk próf verða að vera áhrifarík og verða að vera gagnleg. Við erum með dásamlega forritara, sem vissulega þarf að nefna, því sumir þeirra munu líklega sjá þessa skýrslu og þeir skrifa frábæran kóða. En jafnvel dásamlegur kóðinn þeirra er ekki fullkominn og hefur, hefur og mun halda áfram að innihalda villur. Sjálfvirk próf eru nauðsynleg til að finna þessar villur. Ef þetta er ekki raunin, þá erum við annað hvort að skrifa slæmar sjálfvirkar prófanir eða við erum komin á dauðu svæði sem í grundvallaratriðum er ekki í þróun. Í báðum tilvikum erum við að gera eitthvað rangt og nálgun okkar er einfaldlega ekki skynsamleg.
2. Nota skal sjálfvirk próf. Það þýðir ekkert að eyða miklum tíma og fyrirhöfn í að skrifa hugbúnaðarvöru, setja hana í geymslu og gleyma henni. Próf skal keyra og keyra eins reglulega og hægt er.
3. Sjálfvirk próf ættu að virka stöðugt. Óháð tíma dags, ræsistandi og öðrum kerfisstillingum ættu prufukeyrslur að leiða til sömu niðurstöðu. Að jafnaði er þetta tryggt með því að sjálfvirk próf vinna með sérstökum prófunargögnum með föstum kerfisstillingum.
4. Sjálfvirk próf ættu að vinna á þeim hraða sem er viðunandi fyrir verkefnið þitt. Þessi tími er ákveðinn fyrir sig fyrir hvert kerfi. Sumt fólk hefur efni á að vinna allan daginn en öðrum finnst mikilvægt að gera það á nokkrum sekúndum. Ég mun segja þér aðeins síðar hvaða hraðaviðmiðum við náðum í verkefninu okkar.
5. Sjálfvirk prófun ætti að vera sveigjanleg. Það er ekki ráðlegt að neita að prófa virkni einfaldlega vegna þess að við höfum ekki gert það áður eða af einhverjum öðrum ástæðum. utPLSQL setur engar takmarkanir á þróun og Oracle gerir þér í grundvallaratriðum kleift að innleiða ýmislegt. Flest vandamál hafa lausn, það er bara spurning um tíma og fyrirhöfn.
6. Dreifingarhæfni. Við erum með nokkra bása þar sem við þurfum að keyra próf. Á hverjum bás er hægt að uppfæra gagnageymslu hvenær sem er. Nauðsynlegt er að framkvæma verkefni með sjálfvirkum prófum á þann hátt að þú getur sársaukalaust framkvæmt að fullu eða hluta uppsetningu þess.

Og í annarri færslu eftir nokkra daga mun ég segja þér hvað við gerðum og hvaða árangri við náðum.

Heimild: www.habr.com