Hei Habr!
Fy enw i yw Maxim Ponomarenko ac rwy'n ddatblygwr yn Sportmaster. Mae gen i 10 mlynedd o brofiad yn y maes TG. Dechreuodd ei yrfa mewn profion llaw, yna newidiodd i ddatblygu cronfa ddata. Am y 4 blynedd diwethaf, gan gasglu'r wybodaeth a gafwyd wrth brofi a datblygu, rwyf wedi bod yn awtomeiddio profion ar lefel DBMS.
Rwyf wedi bod ar dîm Sportmaster ers ychydig dros flwyddyn ac yn datblygu profion awtomataidd ar un o'r prosiectau mawr. Ym mis Ebrill, siaradodd y bechgyn o Sportmaster Lab a minnau mewn cynhadledd yn Krasnodar, galwyd fy adroddiad yn “Unit tests in a DBMS,” a nawr rydw i eisiau ei rannu gyda chi. Bydd llawer o destun, felly penderfynais rannu'r adroddiad yn ddwy swydd. Yn y cyntaf, byddwn yn siarad am awtobrofion a phrofion yn gyffredinol, ac yn yr ail, byddaf yn canolbwyntio'n fwy manwl ar ein system profi uned a chanlyniadau ei gymhwyso.
Yn gyntaf, ychydig o ddamcaniaeth ddiflas. Beth yw profi awtomataidd? Profi yw hwn sy'n cael ei wneud gan ddefnyddio meddalwedd, ac mewn TG modern fe'i defnyddir fwyfwy wrth ddatblygu meddalwedd. Mae hyn oherwydd y ffaith bod cwmnïau'n tyfu, mae eu systemau gwybodaeth yn tyfu ac, yn unol â hynny, mae faint o ymarferoldeb y mae angen ei brofi yn tyfu. Mae cynnal profion â llaw yn dod yn fwyfwy drud.
Roeddwn i'n gweithio i gwmni mawr y mae ei ddatganiadau'n dod allan bob dau fis. Ar yr un pryd, treuliwyd mis cyfan ar gael dwsin o brofwyr i wirio'r ymarferoldeb â llaw. Diolch i weithredu awtomeiddio gan dîm bach o ddatblygwyr, roeddem yn gallu lleihau amser profi i 2 wythnos mewn blwyddyn a hanner. Rydym nid yn unig wedi cynyddu cyflymder y profion, ond hefyd wedi gwella ei ansawdd. Mae profion awtomataidd yn cael eu lansio'n rheolaidd ac maent bob amser yn cynnal y cwrs cyfan o wiriadau a gynhwysir ynddynt, hynny yw, rydym yn eithrio'r ffactor dynol.
Nodweddir TG modern gan y ffaith y gallai fod yn ofynnol i ddatblygwr nid yn unig ysgrifennu cod cynnyrch, ond hefyd ysgrifennu profion uned sy'n gwirio'r cod hwn.
Ond beth os yw'ch system yn seiliedig yn bennaf ar resymeg gweinydd? Nid oes unrhyw ateb cyffredinol nac arferion gorau ar y farchnad. Fel rheol, mae cwmnïau'n datrys y broblem hon trwy greu eu system brofi hunan-ysgrifenedig eu hunain. Dyma ein system brofi awtomataidd hunan-ysgrifenedig ein hunain a gafodd ei chreu ar ein prosiect a byddaf yn siarad amdani yn fy adroddiad.
Profi teyrngarwch
Yn gyntaf, gadewch i ni siarad am y prosiect lle buom yn defnyddio system brofi awtomataidd. Ein prosiect yw system teyrngarwch Sportmaster (gyda llaw, rydym eisoes wedi ysgrifennu amdano yn ).
Os yw'ch cwmni'n ddigon mawr, yna bydd gan eich system teyrngarwch dri eiddo safonol:
- Bydd eich system yn llwythog iawn
- Bydd eich system yn cynnwys prosesau cyfrifiadurol cymhleth
- Bydd eich system yn cael ei gwella'n weithredol.
Gadewch i ni fynd mewn trefn... Yn gyfan gwbl, os ydym yn ystyried holl frandiau Sportmaster, yna mae gennym fwy na 1000 o siopau yn Rwsia, Wcráin, Tsieina, Kazakhstan a Belarus. Mae tua 300 o bryniadau yn cael eu gwneud yn y siopau hyn bob dydd. Hynny yw, mae pob eiliad 000-3 siec yn mynd i mewn i'n system. Yn naturiol, mae ein system teyrngarwch yn llwythog iawn. A chan ei fod yn cael ei ddefnyddio'n weithredol, rhaid inni ddarparu'r safonau uchaf o'i ansawdd, oherwydd mae unrhyw gamgymeriad yn y meddalwedd yn golygu colledion ariannol, enw da a cholledion eraill.
Ar yr un pryd, mae Sportmaster yn rhedeg mwy na chant o wahanol hyrwyddiadau. Mae yna amrywiaeth o hyrwyddiadau: mae yna hyrwyddiadau cynnyrch, mae yna rai sy'n ymroddedig i ddiwrnod yr wythnos, mae yna rai sy'n gysylltiedig â siop benodol, mae yna hyrwyddiadau ar gyfer swm y dderbynneb, mae yna ar gyfer nifer y nwyddau. Yn gyffredinol, nid yn ddrwg. Mae gan gleientiaid fonysau a chodau hyrwyddo a ddefnyddir wrth brynu. Mae hyn i gyd yn arwain at y ffaith nad yw cyfrifo unrhyw drefn yn dasg ddibwys iawn.
Mae'r algorithm sy'n gweithredu prosesu archebion yn wirioneddol ofnadwy a chymhleth. Ac mae unrhyw newidiadau i'r algorithm hwn yn eithaf peryglus. Roedd yn ymddangos y gallai'r newidiadau mwyaf di-nod i bob golwg arwain at effeithiau eithaf anrhagweladwy. Ond prosesau cyfrifiadurol mor gymhleth, yn enwedig y rhai sy'n gweithredu swyddogaethau hanfodol, yw'r ymgeiswyr gorau ar gyfer awtomeiddio. Mae gwirio dwsinau o achosion tebyg â llaw yn cymryd llawer o amser. A chan nad yw'r pwynt mynediad i'r broses wedi newid, ar ôl ei ddisgrifio unwaith, gallwch greu profion awtomatig yn gyflym a bod yn hyderus y bydd y swyddogaeth yn gweithio.
Gan fod ein system yn cael ei defnyddio'n weithredol, bydd y busnes eisiau rhywbeth newydd gennych chi, yn byw gyda'r oes ac yn canolbwyntio ar y cwsmer. Yn ein system teyrngarwch, mae datganiadau yn dod allan bob dau fis. Mae hyn yn golygu bod angen i ni gyflawni atchweliad llwyr o'r system gyfan bob dau fis. Ar yr un pryd, yn naturiol, fel mewn unrhyw TG modern, nid yw datblygiad yn mynd yn syth o'r datblygwr i'r cynhyrchiad. Mae'n tarddu ar gylched y datblygwr, yna'n olynol yn mynd trwy'r fainc brawf, rhyddhau, derbyn, a dim ond wedyn yn dod i ben yn y cynhyrchiad. O leiaf, ar y cylchedau prawf a rhyddhau, mae angen inni gyflawni atchweliad cyflawn o'r system gyfan.
Mae'r eiddo a ddisgrifir yn safonol ar gyfer bron unrhyw system teyrngarwch. Gadewch i ni siarad am nodweddion ein prosiect.
Yn dechnolegol, mae 90% o resymeg ein system teyrngarwch yn seiliedig ar weinydd ac yn cael ei weithredu ar Oracle. Mae cleient yn agored yn Delphi, sy'n cyflawni swyddogaeth gweinyddwr gweithle awtomataidd. Mae gwasanaethau gwe agored ar gyfer cymwysiadau allanol (er enghraifft gwefan). Felly, mae'n rhesymegol iawn, os byddwn yn defnyddio system brofi awtomataidd, y byddwn yn ei wneud ar Oracle.
Mae'r system teyrngarwch yn Sportmaster wedi bodoli ers mwy na 7 mlynedd ac fe'i crëwyd gan ddatblygwyr sengl... Nifer cyfartalog y datblygwyr ar ein prosiect yn ystod y 7 mlynedd hyn oedd 3-4 o bobl. Ond dros y flwyddyn ddiwethaf, mae ein tîm wedi tyfu'n sylweddol, a nawr mae 10 o bobl yn gweithio ar y prosiect. Hynny yw, mae pobl yn dod i'r prosiect nad ydyn nhw'n gyfarwydd â thasgau, prosesau a phensaernïaeth nodweddiadol. Ac mae mwy o risg y byddwn yn methu camgymeriadau.
Nodweddir y prosiect gan absenoldeb profwyr penodedig fel unedau staff. Mae yna brofion, wrth gwrs, ond mae dadansoddwyr yn cynnal profion, yn ogystal â'u prif gyfrifoldebau eraill: cyfathrebu â chwsmeriaid busnes, defnyddwyr, datblygu gofynion system, ac ati. ac ati... Er gwaethaf y ffaith bod profion yn cael eu cynnal o ansawdd uchel iawn (mae hyn yn arbennig o briodol i'w grybwyll, gan y gallai rhai o'r dadansoddwyr ddal llygad yr adroddiad hwn), nid yw effeithiolrwydd arbenigo a chanolbwyntio ar un peth wedi'i ganslo .
O ystyried pob un o'r uchod, er mwyn gwella ansawdd y cynnyrch a ddarperir a lleihau amser datblygu, mae'r syniad o awtomeiddio profion ar brosiect yn ymddangos yn rhesymegol iawn. Ac ar wahanol gamau o fodolaeth y system teyrngarwch, gwnaeth datblygwyr unigol ymdrechion i gwmpasu eu cod gyda phrofion uned. Ar y cyfan roedd yn broses weddol ddigyswllt, gyda phawb yn defnyddio eu pensaernïaeth a’u dulliau eu hunain. Roedd y canlyniadau terfynol yn gyffredin i brofion uned: datblygwyd profion, a ddefnyddiwyd ers peth amser, eu storio mewn storfa ffeiliau fersiwn, ond ar ryw adeg fe wnaethant roi'r gorau i redeg ac fe'u hanghofiwyd. Yn gyntaf oll, roedd hyn oherwydd y ffaith bod y profion yn fwy cysylltiedig â pherfformiwr penodol, ac nid i'r prosiect.
utPLSQL yn dod i'r adwy
Ydych chi'n gwybod unrhyw beth am Stephen Feuerstein?
Mae hwn yn foi craff a ymroddodd ran hir o'i yrfa i weithio gydag Oracle a PL/SQL, ac sydd wedi ysgrifennu nifer eithaf mawr o weithiau ar y pwnc hwn. Enw un o’i lyfrau enwog yw: “Oracle PL/SQL. Ar gyfer gweithwyr proffesiynol." Stephen a ddatblygodd y datrysiad utPLSQL, neu, fel y mae, fframwaith Profi Uned ar gyfer Oracle PL/SQL. Crëwyd yr ateb utPLSQL yn 2016, ond mae'n parhau i gael ei weithio arno ac mae fersiynau newydd yn cael eu rhyddhau. Ar adeg yr adroddiad, mae'r fersiwn ddiweddaraf yn dyddio'n ôl i Fawrth 24, 2019.
Beth ydyw. Mae hwn yn brosiect ffynhonnell agored ar wahân. Mae'n pwyso cwpl o megabeit, gan gynnwys enghreifftiau a dogfennaeth. Yn gorfforol, mae'n sgema ar wahân yng nghronfa ddata ORACLE gyda set o becynnau a thablau ar gyfer trefnu profion uned. Mae'r gosodiad yn cymryd ychydig eiliadau. Nodwedd arbennig o utPLSQL yw ei hwylustod i'w ddefnyddio.
Yn fyd-eang, mae utPLSQL yn fecanwaith ar gyfer cynnal profion uned, lle mae prawf uned yn cael ei ddeall fel gweithdrefnau swp arferol Oracle, y mae eu trefniadaeth yn dilyn rhai rheolau. Yn ogystal â lansio, mae utPLSQL yn storio log o'ch holl rediadau prawf, ac mae ganddo hefyd system adrodd fewnol.
Gadewch i ni edrych ar enghraifft o sut olwg sydd ar god prawf yr uned, a weithredir gan ddefnyddio'r dechneg hon.
Felly, mae'r sgrin yn dangos y cod ar gyfer manyleb pecyn nodweddiadol gyda phrofion uned. Beth yw'r gofynion gorfodol? Rhaid rhoi "utp_" ar y pecyn. Rhaid i bob gweithdrefn â phrofion gael yr un rhagddodiad yn union. Rhaid i'r pecyn gynnwys dwy weithdrefn safonol: “utp_setup” ac “utp_teardown”. Gelwir y weithdrefn gyntaf trwy ailgychwyn pob prawf uned, yr ail - ar ôl ei lansio.
Mae “utp_setup”, fel rheol, yn paratoi ein system i redeg prawf uned, er enghraifft, creu data prawf. “utp_teardown” - i'r gwrthwyneb, mae popeth yn dychwelyd i'r gosodiadau gwreiddiol ac yn ailosod y canlyniadau lansio.
Dyma enghraifft o'r prawf uned symlaf sy'n gwirio normaleiddio'r rhif ffôn cwsmer a gofnodwyd i'r ffurflen safonol ar gyfer ein system teyrngarwch. Nid oes unrhyw safonau gorfodol ar sut i ysgrifennu gweithdrefnau gyda phrofion uned. Fel rheol, gwneir galwad i ddull o'r system dan brawf, ac mae'r canlyniad a ddychwelir gan y dull hwn yn cael ei gymharu â'r cyfeirnod un. Mae'n bwysig bod y canlyniad cyfeirio a'r un a gafwyd yn cael ei gymharu trwy ddulliau utPLSQL safonol.
Gall prawf uned gael unrhyw nifer o wiriadau. Fel y gwelir o'r enghraifft, rydym yn gwneud pedwar galwad yn olynol i'r dull a brofwyd i normaleiddio'r rhif ffôn a gwerthuso'r canlyniad ar ôl pob galwad. Wrth ddatblygu prawf uned, rhaid i chi ystyried bod yna wiriadau nad ydynt yn effeithio ar y system mewn unrhyw ffordd, ac ar ôl rhai mae angen i chi rolio'n ôl i gyflwr gwreiddiol y system.
Er enghraifft, yn y prawf uned a gyflwynir rydym yn syml yn fformatio'r rhif ffôn mewnbwn, nad yw'n effeithio ar y system teyrngarwch mewn unrhyw ffordd.
Ac os ydym yn ysgrifennu profion uned gan ddefnyddio'r dull o greu cleient newydd, yna ar ôl pob prawf bydd cleient newydd yn cael ei greu yn y system, a all effeithio ar lansiad dilynol y prawf.
Dyma sut mae profion uned yn cael eu rhedeg. Mae dau opsiwn lansio posibl: rhedeg pob prawf uned o becyn penodol neu redeg prawf uned benodol mewn pecyn penodol.
Dyma sut olwg sydd ar enghraifft o system adrodd fewnol. Yn seiliedig ar ganlyniadau'r prawf uned, mae utPLSQL yn adeiladu adroddiad bach. Ynddo fe welwn y canlyniad ar gyfer pob gwiriad penodol a chanlyniad cyffredinol y prawf uned.
6 rheol awtobrofion
Cyn dechrau creu system newydd ar gyfer profi’r system teyrngarwch yn awtomataidd, ynghyd â’r rheolwyr, fe wnaethom bennu’r egwyddorion y dylai ein profion awtomataidd yn y dyfodol gydymffurfio â nhw.
- Rhaid i brofion awto fod yn effeithiol a rhaid iddynt fod yn ddefnyddiol. Mae gennym ni ddatblygwyr gwych, y mae angen eu crybwyll yn bendant, oherwydd mae'n debyg y bydd rhai ohonyn nhw'n gweld yr adroddiad hwn, ac maen nhw'n ysgrifennu cod gwych. Ond nid yw hyd yn oed eu cod gwych yn berffaith ac mae ganddo, a bydd yn parhau i gynnwys gwallau. Mae angen profion awtomatig i ddod o hyd i'r gwallau hyn. Os nad yw hyn yn wir, yna naill ai rydym yn ysgrifennu awtobrofion gwael, neu rydym wedi dod i faes marw nad yw, mewn egwyddor, yn cael ei ddatblygu. Yn y ddau achos, rydym yn gwneud rhywbeth o'i le, ac nid yw ein hymagwedd yn gwneud synnwyr.
- Dylid defnyddio profion awtomatig. Nid yw'n gwneud unrhyw synnwyr i dreulio llawer o amser ac ymdrech ar ysgrifennu cynnyrch meddalwedd, ei roi mewn ystorfa a'i anghofio. Dylid cynnal profion, a'u cynnal mor rheolaidd â phosibl.
- Dylai Autotests weithio'n sefydlog. Waeth beth fo'r amser o'r dydd, stondin lansio a gosodiadau system eraill, dylai rhediadau prawf arwain at yr un canlyniad. Fel rheol, sicrheir hyn gan y ffaith bod autotests yn gweithio gyda data prawf arbennig gyda gosodiadau system sefydlog.
- Dylai profion awto weithio ar gyflymder sy'n dderbyniol ar gyfer eich prosiect. Pennir yr amser hwn yn unigol ar gyfer pob system. Gall rhai pobl fforddio gweithio drwy'r dydd, tra bod eraill yn ei chael hi'n hanfodol gwneud hynny mewn eiliadau. Byddaf yn dweud wrthych ychydig yn ddiweddarach pa safonau cyflymder a gyflawnwyd gennym yn ein prosiect.
- Dylai datblygiad Autotest fod yn hyblyg. Nid yw'n ddoeth gwrthod rhoi prawf ar unrhyw swyddogaethau dim ond oherwydd nad ydym wedi'i wneud o'r blaen neu am ryw reswm arall. Nid yw utPLSQL yn gosod unrhyw gyfyngiadau ar ddatblygiad, ac mae Oracle, mewn egwyddor, yn caniatáu ichi weithredu amrywiaeth o bethau. Mae gan y rhan fwyaf o broblemau ateb, dim ond mater o amser ac ymdrech ydyw.
- Defnyddioldeb. Mae gennym ni sawl stondin lle mae angen i ni gynnal profion. Ar bob stondin, gellir diweddaru dympio data ar unrhyw adeg. Mae angen cynnal prosiect gyda phrofion awtomatig yn y fath fodd fel y gallwch chi wneud ei osodiad llawn neu rannol yn ddi-boen.
Ac yn yr ail bost mewn cwpl o ddiwrnodau byddaf yn dweud wrthych beth a wnaethom a pha ganlyniadau a gyflawnwyd gennym.
Ffynhonnell: hab.com