Skip to content
Բոլոր հոդվածները
Ստանդարտներ և մեթոդիկա

Ինչպես ենք ավտոմատացնում ցանցի ռեգրեսիոն թեստերը

Alexander Zemskov 4 րոպե ընթերցում
Ինչպես ենք ավտոմատացնում ցանցի ռեգրեսիոն թեստերը

Նոր որոնվածի release notes-ում գրված է՝ «սխալների ուղղում և արտադրողականության բարելավում»։ Արտահայտության երկրորդ կեսը ոչ ոք չի չափում։ Ձեռքով ռեգրեսիան ինժեներից խլում է 2–3 օր յուրաքանչյուր թողարկման համար, և ամեն ժամկետ դրանից մի քանի կետ է հանում, առաջինը՝ ամենաերկարները. կոնվերգենցիան լրիվ աղյուսակով, կադրերի չափերով գործարկումը, 40 կետանոց ստուգաթերթը։ Այդ ցուցակը մենք վերածում ենք ռեգրեսիոն հավաքածուի, որը վերագործարկվում է որոնվածի, կոնֆիգուրացիայի կամ թողարկման ամեն փոփոխության վրա և արդյունքը համեմատում Ձեր հաստատած վերջին build-ի հետ։

Ստենդը

CloudLAB-ի բաժանորդագրության դեպքում սարքը սեսիաների միջև մնում է ստենդում։ Ավտոմատ կոմուտացիան այն միացնում է ստենդի գեներատորներին կամ մեր սեփական տրաֆիկի գեներատորին, ուստի գործարկմանը պետք չեն ո՛չ հայտ, ո՛չ էլ ինժեներ սենյակում։ Սարքը կարգավորվում է իր API-ով, իսկ եթե API չկա, սկրիպտն աշխատում է կոնսոլի կամ վեբ ինտերֆեյսի հետ՝ ավելի դանդաղ և ինտերֆեյսի փոփոխության դեպքում խափանվելու ռիսկով։

Յուրաքանչյուր test case կոդ է Ձեր ռեպոզիտորիայում՝ տոպոլոգիա, սարքի կոնֆիգուրացիա, տրաֆիկի պրոֆիլ, բեռի աստիճաններ, տևողություն, pass չափանիշ։ Ձեր CI job-ը կանչում է հավաքածուն API-ով կամ CLI-ով՝ build-ի համարով, և վճիռը ստանում է unit թեստերի կողքին, գիշերային ժամանակացույցն օգտագործում է նույն մուտքի կետը։ Թե ինչու պետք է անվտանգության պլատֆորմները վերստուգել ամեն թարմացումից հետո, քննարկել ենք առանձին գրառման մեջ։ Այստեղ խոսքը մեխանիկայի մասին է։

Ինչ ենք ստուգում

  • Սկզբնական վիճակ. սարքի հաղորդած որոնվածի տարբերակը, սկրիպտով կիրառված կոնֆիգուրացիան, հաշվիչները առաջին test case-ից առաջ և վերջինից հետո
  • Throughput և latency 1G-ից 100G պորտերում՝ Ձեր կադրերի չափերով և տրաֆիկի պրոֆիլով, baseline-ի դիմաց
  • Latency p99 բեռի յուրաքանչյուր աստիճանում, որտեղ կոդի ավելի դանդաղ ճանապարհը հաճախ երևում է ավելի շուտ, քան կշարժվի առավելագույն արագությունը
  • Կոնվերգենցիա և failover երթուղիների կամ սեսիաների լրիվ աղյուսակով. կապուղու կորուստ, հարևանի կորուստ, HA փոխարկում, ընդհատումը յուրաքանչյուր հոսքի համար միլիվայրկյաններով
  • Ֆունկցիոնալ ստուգաթերթ՝ 40-ից 150 կետ, յուրաքանչյուրի համար տրաֆիկի capture, հայտնի խնդիրները նշված են որպես known
  • Անվտանգության արտադրողականություն միացված ստուգմամբ. throughput, միացումներ վայրկյանում, միաժամանակյա սեսիաներ
  • Դրեյֆ. յուրաքանչյուր KPI վերջին build-երի ընթացքում՝ կողք կողքի

Յուրաքանչյուր KPI ունի թույլատրելի շեղում, որը համաձայնեցվում է Ձեր թիմի հետ առաջին ավտոմատ գործարկումից առաջ՝ մի քանի տոկոս throughput-ի համար, ֆիքսված սահման միլիվայրկյաններով կոնվերգենցիայի համար, զրո ֆունկցիոնալ կետի համար։ Baseline-ը առաջին լրիվ գործարկումն է այն build-ի վրա, որին Դուք վստահում եք։ Այն պահվում է կոնֆիգուրացիայի, տրաֆիկի պրոֆիլի և ստենդի սխեմայի հետ, որպեսզի հաջորդ գործարկումները համեմատվեն նույնի հետ։

Ինչն է սովորաբար խափանվում

Լուռ ռեգրեսիա։ Գիշերային գործարկման օրինակ միջուկային երթուղիչի build-ի վրա. ստուգաթերթի 38 կետից 37-ն անցնում է, կոնվերգենցիան սահմանի ներսում է, 1518 բայթ կադրերով throughput-ը 6 %-ով ցածր է նախորդ build-ից, latency p99-ը 70 % բեռի դեպքում աճել է 18 %-ով։ Release notes-ում դրանցից ոչ մեկը չկա։ Գործարկումը տևում է 2 ժ 40 ր առանց մարդկանց, և կարմիր արդյունքը pipeline-ում է 06:10-ին։ Ձեռքով 40 կետանոց ստուգաթերթը միջուկային երթուղիչի որոնվածի համար տևում է 2 օր։

Դրեյֆ։ KPI-ը, որը յուրաքանչյուր թողարկման հետ կորցնում է 1 %, անցնում է ամեն առանձին ստուգում և մեկ տարի անց 6 %-ով ցածր է։ Նախորդ build-ի հետ ամեն համեմատություն կանաչ է, հաստատված baseline-ի հետ համեմատությունը՝ ոչ։ Հաշվետվությունը պահում է երկուսն էլ։

Կեղծ տագնապ բարձրացնող հավաքածու։ Առաջին շաբաթներին կարմիր գործարկումը հաճախ հենց հավաքածուի մեղքն է՝ վեբ ձև, որտեղ դաշտը տեղափոխվել է, այլ տրաֆիկի պրոֆիլով վերցված baseline, զրոյական շեղում KPI-ի համար, որը գործարկումների միջև տատանվում է 2 %-ով։ Յուրաքանչյուր նման դեպք ուղղվում է հավաքածուում և գրանցվում, որպեսզի հետագայում կարմիր սյունը ցույց տա սարքը։

Ինչ կա հաշվետվության մեջ

Մեկ էջ, որը Ձեր թիմը կարդում է 5 րոպեում՝ ինչ է փոխվել վերջին հաստատված build-ից հետո, pass, fail կամ known յուրաքանչյուր կետի համար, KPI-ների diff-ը նախորդ build-ի և baseline-ի նկատմամբ, տրենդը։ Դրա հետևում՝ գեներատորի վիճակագրությունը, սարքի հաշվիչները առաջ և հետո, յուրաքանչյուր ձախողված կետի capture-ը, կոնսոլի լոգը։ Սկրիպտները, կոնֆիգուրացիան, շեմերը և գործարկումների պատմությունը փոխանցվում են Ձեր ռեպոզիտորիա փաստաթղթերով, ուստի հավաքածուն աշխատում է նաև Ձեր լաբորատորիայում։ Առաջին հավաքածուն պահանջում է 3 շաբաթից՝ սկսած ձեռքով գործարկումից, որը տալիս է թեստի պլանը և baseline-ը։

Որտեղից սկսել

Ուղարկեք մեզ այն ցուցակը, որը գործարկում եք թողարկումից առաջ, սարքի մոդելը և թե ինչպես է Ձեր pipeline-ը գործարկում job-երը։ Մենք պատասխանում ենք թեստի պլանի նախագծով՝ կետերը, ստենդի սխեման և ժամկետները։ Սկրիպտները և հաշվետվությունը մնում են Ձեզ, և Դուք կարող եք այն ցույց տալ վենդորին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։

Հեղինակ

Alexander Zemskov

Ցանցերի և անվտանգության թեստավորման փորձագետ և վաճառք (19+ տարի) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel և այլն

Բլոգ

Կարդացեք նաև

Երթուղավորում և կոմուտացիա

Ինչպես ենք փորձարկում PoE-ն. բյուջե, առաջնահերթություն, PSU

PoE կոմուտատորի բնութագրում գնորդը կարդում է երկու տող՝ «PoE+ բոլոր 48 պորտերում» և հզորության բյուջեն, օրինակ՝ 740 Վտ։ 48 պորտը 30-ական Վտ-ով կազմում է 1440 Վտ։ Երկու տո…

Alexander Zemskov 4 րոպե ընթերցում
Ստանդարտներ և մեթոդիկա Երթուղավորում և կոմուտացիա

Բազմավենդոր ցանցի փորձարկում. մեկ RFC, երկու ընթերցում

Երկու երթուղիչ երկու վենդորից, և երկու բնութագրերում էլ RFC-ների նույն ցանկն է։ Երկուսն էլ ճիշտ են։ RFC-ն տարբերակներ է թողնում, յուրաքանչյուր վենդոր ընտրում է իր լռելյայ…

Alexander Zemskov 4 րոպե ընթերցում
Անվտանգություն

Ինչպես ենք փորձարկում հեռավոր աշխատանքի VPN-ը. MFA և failover

VPN կոնցենտրատորի բնութագրում երկու թիվ կա՝ օգտատերերի քանակը և throughput-ը, և դրանք չափված են առանձին։ Առաջինը՝ հազարավոր դատարկ թունելներով, երկրորդը՝ մի քանի հաստ թու…

Alexander Zemskov 4 րոպե ընթերցում