සංවර්ධකයින් සඳහා CI සේවාවක් ලෙස පැටවීම පරීක්ෂා කිරීම

බහු නිෂ්පාදන මෘදුකාංග වෙළෙන්දන් බොහෝ විට මුහුණ දෙන ගැටලුවක් වන්නේ සෑම කණ්ඩායමකම පාහේ ඉංජිනේරුවන්ගේ - සංවර්ධකයින්, පරීක්ෂකයින් සහ යටිතල පහසුකම් පරිපාලකයින්ගේ නිපුණතා අනුපිටපත් කිරීමයි. මෙය මිල අධික ඉංජිනේරුවන්ට ද අදාළ වේ - බර පරීක්ෂා කිරීමේ ක්ෂේත්රයේ විශේෂඥයින්.

ඔවුන්ගේ සෘජු රාජකාරි ඉටු කිරීම සහ බර පරීක්ෂා කිරීමේ ක්‍රියාවලියක් ගොඩනැගීමට ඔවුන්ගේ අද්විතීය අත්දැකීම් භාවිතා කිරීම වෙනුවට, ක්‍රමවේදයක් තෝරා ගැනීම, ප්‍රශස්ත මිනුම් සහ පැටවුම් පැතිකඩට අනුකූලව ස්වයංක්‍රීය පරීක්ෂණ ලිවීම, ඉංජිනේරුවන්ට බොහෝ විට මුල සිටම පරීක්ෂණ යටිතල පහසුකම් යෙදවීමට, පැටවුම් මෙවලම් වින්‍යාස කිරීමට, ඒවා CI පද්ධතිවලට කාවැද්දීම, අධීක්ෂණ සහ වාර්තා සැකසීමට සිදු වේ.

Positive Technologies හි අප භාවිතා කරන පරීක්ෂණ වලදී ඔබට සමහර ආයතනික ගැටළු වලට විසඳුම් සොයාගත හැක තවත් ලිපියක්. මෙහි දී, “සේවාවක් ලෙස බර පරීක්ෂා කිරීම” (සේවාවක් ලෙස බර පරීක්ෂා කිරීම) යන සංකල්පය භාවිතා කරමින් බර පරීක්ෂණ පොදු CI නල මාර්ගයකට ඒකාබද්ධ කිරීමේ හැකියාව ගැන මම කතා කරමි. CI නල මාර්ගයේ load sources වල docker images භාවිතා කළ හැක්කේ කෙසේද සහ කෙසේද යන්න ඔබ ඉගෙන ගනු ඇත; ගොඩනැගීමේ අච්චුවක් භාවිතයෙන් ඔබේ CI ව්‍යාපෘතියට පැටවුම් මූලාශ්‍ර සම්බන්ධ කරන්නේ කෙසේද; බර පරීක්ෂණ ධාවනය කිරීම සහ ප්‍රතිඵල ප්‍රකාශයට පත් කිරීම සඳහා demo නල මාර්ගය පෙනෙන්නේ කෙසේද? CI හි මෘදුකාංග පරීක්ෂණ ඉංජිනේරුවන් සහ ස්වයංක්‍රීය ඉංජිනේරුවන් සඳහා ලිපිය ප්‍රයෝජනවත් විය හැකිය, ඔවුන් තම භාර පද්ධතියේ ගෘහ නිර්මාණ ශිල්පය ගැන සිතයි.

සංකල්පයේ සාරය

සේවාවක් ලෙස load testing සංකල්පයෙන් ඇඟවෙන්නේ load tools Apache JMeter, Yandex.Tank සහ ඔබේම රාමු අත්තනෝමතික අඛණ්ඩ ඒකාබද්ධ කිරීමේ පද්ධතියකට ඒකාබද්ධ කිරීමේ හැකියාවයි. Demo GitLab CI සඳහා වනු ඇත, නමුත් මූලධර්ම සියලු CI පද්ධති සඳහා පොදු වේ.

සේවාවක් ලෙස බර පරීක්ෂා කිරීම බර පරීක්ෂා කිරීම සඳහා මධ්‍යගත සේවාවකි. පැටවීමේ පරීක්ෂණ කැපවූ නියෝජිත සංචිතවල ක්‍රියාත්මක වේ, ප්‍රතිඵල ස්වයංක්‍රීයව GitLab පිටු, Influx DB සහ Grafana හෝ පරීක්ෂණ වාර්තාකරණ පද්ධතිවල (TestRail, ReportPortal, ආදිය) ප්‍රකාශයට පත් කෙරේ. ස්වයංක්‍රීයකරණය සහ පරිමාණය හැකිතාක් සරලව ක්‍රියාත්මක කෙරේ - GitLab CI ව්‍යාපෘතියේ සුපුරුදු gitlab-ci.yml අච්චුව එකතු කිරීම සහ පරාමිතිකරණය කිරීම මගින්.

ප්‍රවේශයේ වාසිය නම් සමස්ත CI යටිතල ව්‍යුහය, පැටවීමේ නියෝජිතයන්, බර ප්‍රභවයන්ගේ ඩොකර් රූප, පරීක්ෂණ නල මාර්ග සහ වාර්තා කිරීමේ ප්‍රකාශනය මධ්‍යගත ස්වයංක්‍රීය අංශයක් (DevOps ඉංජිනේරුවන්) විසින් නඩත්තු කරනු ලබන අතර, බර පරීක්ෂණ ඉංජිනේරුවන්ට යටිතල ගැටළු සමඟ කටයුතු නොකර පරීක්ෂණ සංවර්ධනය කිරීම සහ ඒවායේ ප්‍රතිඵල විශ්ලේෂණය කිරීම කෙරෙහි තම උත්සාහයන් යොමු කළ හැකිය.

විස්තරයේ සරල බව සඳහා, අපි උපකල්පනය කරමු ඉලක්ක යෙදුම හෝ පරීක්ෂණය යටතේ ඇති සේවාදායකය දැනටමත් යොදවා සහ කල්තියා වින්‍යාස කර ඇත (මේ සඳහා පයිතන්, සෝල්ට්ස්ටැක්, ඇන්සිබල් යනාදී ස්වයංක්‍රීය ස්ක්‍රිප්ට් භාවිතා කළ හැක). එවිට සේවාවක් ලෙස බර පරීක්ෂා කිරීමේ සමස්ත සංකල්පය අදියර තුනකට ගැලපේ: සකස් කිරීම, පරීක්ෂා කිරීම, වාර්තා ප්රකාශ කිරීම. රූප සටහනේ වැඩි විස්තර (සියලු පින්තූර ක්ලික් කළ හැකිය):

බර පරීක්ෂා කිරීමේදී මූලික සංකල්ප සහ නිර්වචන

බර පරීක්ෂණ සිදු කරන විට, අපි පිළිපැදීමට උත්සාහ කරමු ISTQB ප්‍රමිතීන් සහ ක්‍රමවේදය, සුදුසු පාරිභාෂිතය සහ නිර්දේශිත ප්‍රමිතික භාවිතා කරන්න. බර පරීක්ෂා කිරීමේදී ප්‍රධාන සංකල්ප සහ අර්ථ දැක්වීම් පිළිබඳ කෙටි ලැයිස්තුවක් මම දෙන්නෙමි.

පැටවීමේ නියෝජිතයා - යෙදුම දියත් කරනු ලබන අතථ්‍ය යන්ත්‍රයක් - බර ප්‍රභවය (Apache JMeter, Yandex.Tank හෝ ස්වයං-ලිඛිත පැටවුම් මොඩියුලයක්).

ටෙස්ට් ඉලක්කය (ඉලක්කය) - පූරණයට යටත් වන සේවාදායකයේ ස්ථාපනය කර ඇති සේවාදායකය හෝ යෙදුම.

පරීක්ෂණ අවස්ථාව (පරීක්ෂණ නඩුව) - පරාමිතික පියවර මාලාවක්: නිශ්චිත පරාමිති මත පදනම්ව, ස්ථාවර ජාල ඉල්ලීම් සහ ප්‍රතිචාර සමඟ, පරිශීලක ක්‍රියා සහ මෙම ක්‍රියාවන්ට අපේක්ෂිත ප්‍රතික්‍රියා.

පැතිකඩ හෝ පැටවීමේ සැලැස්ම (පැතිකඩ) - හිදී ISTQB ක්‍රමවේදය (වගන්තිය 4.2.4, පි. 43) පැටවුම් පැතිකඩ විශේෂිත පරීක්ෂණයක් සඳහා තීරණාත්මක වන ප්‍රමිතික සහ පරීක්ෂණය අතරතුර බර පරාමිතීන් වෙනස් කිරීම සඳහා විකල්ප නිර්වචනය කරයි. රූපයේ පැතිකඩ සඳහා උදාහරණ ඔබට දැක ගත හැකිය.

පරීක්ෂණය - කලින් තීරණය කරන ලද පරාමිති කට්ටලයක් සහිත ස්ක්‍රිප්ට් එකක්.

පරීක්ෂණ සැලැස්ම (පරීක්ෂණ සැලැස්ම) - පරීක්ෂණ කට්ටලයක් සහ පැටවුම් පැතිකඩක්.

Testran (පරීක්ෂණ) - සම්පුර්ණයෙන්ම ක්‍රියාත්මක කරන ලද බර දර්ශනයක් සහ ලැබුණු වාර්තාවක් සමඟ එක් පරීක්ෂණයක් ධාවනය කිරීමේ එක් පුනරාවර්තනයක්.

ජාල ඉල්ලීම (ඉල්ලීම) - HTTP ඉල්ලීමක් නියෝජිතයෙකුගෙන් ඉලක්කයක් වෙත යවනු ලැබේ.

ජාල ප්‍රතිචාරය (ප්‍රතිචාරය) - HTTP ප්‍රතිචාරයක් ඉලක්කයේ සිට නියෝජිතයා වෙත යවනු ලැබේ.
HTTP ප්‍රතිචාර කේතය (HTTP ප්‍රතිචාර තත්ත්වය) - යෙදුම් සේවාදායකයෙන් සම්මත ප්‍රතිචාර කේතය.
ගනුදෙනුවක් යනු සම්පූර්ණ ඉල්ලීම්-ප්‍රතිචාර චක්‍රයකි. ඉල්ලීමක් (ඉල්ලීමක්) යැවීමේ ආරම්භයේ සිට ප්‍රතිචාරයක් (ප්‍රතිචාරයක්) ලැබීම අවසන් වන තෙක් ගනුදෙනුවක් ගණනය කෙරේ.

ගනුදෙනු තත්ත්වය - ඉල්ලීම්-ප්‍රතිචාර චක්‍රය සාර්ථකව සම්පූර්ණ කිරීමට හැකි වූයේද යන්න. මෙම චක්‍රයේ යම් දෝෂයක් තිබුනේ නම්, සම්පූර්ණ ගනුදෙනුව අසාර්ථක ලෙස සලකනු ලැබේ.

ප්‍රතිචාර කාලය (ප්‍රමාදය) - ඉල්ලීමක් (ඉල්ලීමක්) යැවීමේ අවසානයේ සිට ප්‍රතිචාරයක් ලැබීමේ ආරම්භය දක්වා කාලය (ප්‍රතිචාරය).

ප්‍රමිතික පූරණය කරන්න - පටවන ලද සේවාවේ ලක්ෂණ සහ බර පරීක්ෂා කිරීමේ ක්රියාවලියේදී තීරණය කරන ලද භාර නියෝජිතයා.

බර පරාමිතීන් මැනීම සඳහා මූලික මිනුම්

ක්රමවේදය තුළ බහුලව භාවිතා වන සහ නිර්දේශිත සමහරක් ISTQB (පි. 36, 52) ප්‍රමිතික පහත වගුවේ දක්වා ඇත. නියෝජිතයා සහ ඉලක්කය සඳහා සමාන ප්‍රමිතික එකම රේඛාවේ ලැයිස්තුගත කර ඇත.

පැටවීමේ නියෝජිතයා සඳහා මිනුම්
බර යටතේ පරීක්ෂා කරනු ලබන ඉලක්ක පද්ධතියේ හෝ යෙදුමේ ප්‍රමිතික

ගණන  vCPU සහ මතකය RAM,
තැටිය - බඩු කාරකයේ "යකඩ" ලක්ෂණ
CPU, මතකය, තැටි භාවිතය - CPU වල ගතිකත්වය, මතකය සහ තැටි පැටවීම
පරීක්ෂණ ක්රියාවලිය තුළ. සාමාන්යයෙන් ප්රතිශතයක් ලෙස මනිනු ලැබේ
ලබා ගත හැකි උපරිම අගයන්

ජාල ප්‍රතිදානය (බර කාරකය මත) - ප්‍රතිදානය
සේවාදායකයේ ජාල අතුරුමුහුණත,
load agent ස්ථාපනය කර ඇති තැන.
සාමාන්‍යයෙන් මනිනු ලබන්නේ තත්පරයට බයිට් වලින් (bps)
ජාල ප්‍රතිදානය(ඉලක්කය මත) - ජාල අතුරුමුහුණත් කලාප පළල
ඉලක්ක සේවාදායකය මත. සාමාන්‍යයෙන් මනිනු ලබන්නේ තත්පරයට බයිට් වලින් (bps)

අතථ්‍ය පරිශීලකයන්- අතථ්‍ය පරිශීලකයින් සංඛ්‍යාව,
පැටවීමේ අවස්ථා ක්රියාත්මක කිරීම සහ
සැබෑ පරිශීලක ක්රියා අනුකරණය කිරීම
අතථ්‍ය පරිශීලක තත්ත්වය, සමත්/අසාර්ථක/මුළු - සාර්ථක සංඛ්‍යාව සහ
අතථ්‍ය පරිශීලකයන්ගේ අසාර්ථක තත්ත්වයන්
පැටවීමේ අවස්ථා සඳහා මෙන්ම, ඔවුන්ගේ මුළු සංඛ්යාව.

සියලුම පරිශීලකයින්ට සම්පූර්ණ කිරීමට හැකි වූ බව සාමාන්යයෙන් අපේක්ෂා කෙරේ
පැටවුම් පැතිකඩෙහි දක්වා ඇති ඔබගේ සියලු කාර්යයන්.
ඕනෑම දෝෂයක් සැබෑ පරිශීලකයෙකුට නොහැකි වනු ඇත
පද්ධතිය සමඟ වැඩ කිරීමේදී ඔබේ ගැටලුව විසඳන්න

තත්පරයකට ඉල්ලීම් (විනාඩි)- තත්පරයකට ජාල ඉල්ලීම් ගණන (හෝ මිනිත්තුවකට).

පැටවීමේ නියෝජිතයෙකුගේ වැදගත් ලක්ෂණයක් වන්නේ එය කොපමණ ඉල්ලීම් උත්පාදනය කළ හැකිද යන්නයි.
ඇත්ත වශයෙන්ම, මෙය අතථ්‍ය පරිශීලකයින් විසින් යෙදුමට ප්‍රවේශ වීම අනුකරණය කිරීමකි
තත්පරයට ප්‍රතිචාර (විනාඩි)
- තත්පරයකට ජාල ප්‍රතිචාර ගණන (හෝ මිනිත්තුවකට).

ඉලක්කගත සේවාවෙහි වැදගත් ලක්ෂණයක්: කොපමණ
සමඟ විමසුම් සඳහා ප්‍රතිචාර ජනනය කර යැවීම
පැටවීමේ නියෝජිතයා

HTTP ප්රතිචාර තත්ත්වය- විවිධ ප්‍රතිචාර කේත ගණන
පැටවුම් නියෝජිතයා විසින් ලැබුණු යෙදුම් සේවාදායකයෙන්.
උදාහරණයක් ලෙස, 200 OK යනු සාර්ථක ඇමතුමක්,
සහ 404 - සම්පත සොයාගත නොහැකි විය

කාලගුණය (ප්රතිචාර කාලය) - අවසානයේ සිට කාලය
ප්රතිචාරයක් (ප්රතිචාරයක්) ලැබීමට පෙර ඉල්ලීමක් (ඉල්ලීමක්) යැවීම.
සාමාන්‍යයෙන් මනිනු ලබන්නේ මිලි තත්පර වලින් (ms)

ගනුදෙනු ප්රතිචාර කාලය- එක් සම්පූර්ණ ගනුදෙනුවක කාලය,
ඉල්ලීම්-ප්‍රතිචාර චක්‍රය සම්පූර්ණ කිරීම.
ඉල්ලීම යැවීමේ ආරම්භයේ සිට කාලය මෙයයි (ඉල්ලීම)
ප්රතිචාරයක් ලැබීම අවසන් වන තුරු (ප්රතිචාරය).

ගනුදෙනු කාලය තත්පර (හෝ මිනිත්තු) වලින් මැනිය හැක
ක්රම කිහිපයකින්: අවම වශයෙන් සලකා බලන්න,
උපරිම, සාමාන්ය සහ, උදාහරණයක් ලෙස, 90 වැනි ප්රතිශතය.
අවම සහ උපරිම කියවීම් අන්ත වේ
පද්ධති කාර්ය සාධන තත්ත්වය.
අනූවන ප්‍රතිශතය වඩාත් බහුලව භාවිතා වේ,
එය බොහෝ පරිශීලකයින් පෙන්වන පරිදි,
පද්ධති ක්‍රියාකාරිත්වයේ එළිපත්තෙහි සුවපහසු ලෙස ක්‍රියා කරයි

තත්පරයට ගනුදෙනු (විනාඩි) - සම්පූර්ණ සංඛ්යාව
තත්පරයට ගනුදෙනු (විනාඩි),
එනම්, අයදුම්පත කොපමණ ප්රමාණයක් පිළිගත හැකි විය සහ
ඉල්ලීම් සැකසීම සහ ප්‍රතිචාර නිකුත් කිරීම.
ඇත්ත වශයෙන්ම, මෙය පද්ධතියේ ප්‍රතිදානයයි

ගනුදෙනු තත්ත්වය , සමත් / අසාර්ථක / මුළු - අංකය
සාර්ථක, අසාර්ථක සහ මුළු ගනුදෙනු ගණන.

සැබෑ පරිශීලකයින් සඳහා අසාර්ථකයි
ගනුදෙනුව ඇත්ත වශයෙන්ම අදහස් වනු ඇත
පැටවීම යටතේ පද්ධතිය සමඟ වැඩ කිරීමට නොහැකි වීම

පැටවීමේ පරීක්ෂණ ක්‍රමානුරූප රූප සටහන

බර පරීක්ෂා කිරීමේ සංකල්පය ඉතා සරල වන අතර මා දැනටමත් සඳහන් කර ඇති ප්රධාන අදියර තුනකින් සමන්විත වේ: සූදානම්-පරීක්ෂණ-වාර්තාව, එනම්, පරීක්ෂණ ඉලක්ක සකස් කිරීම සහ බර ප්‍රභවයන් සඳහා පරාමිතීන් සැකසීම, පසුව බර පරීක්ෂණ ක්‍රියාත්මක කිරීම සහ අවසානයේ පරීක්ෂණ වාර්තාවක් ජනනය කිරීම සහ ප්‍රකාශයට පත් කිරීම.

ක්රමානුරූප සටහන්:

• QA.Tester යනු බර පරීක්ෂා කිරීමේ විශේෂඥයෙකි,
• Target යනු ඔබට බර යටතේ එහි හැසිරීම දැන ගැනීමට අවශ්‍ය ඉලක්ක යෙදුමයි.

රූප සටහනේ ඇති ආයතන, අදියර සහ පියවර වර්ගීකරණය

අදියර සහ පියවර
සිද්ධවන්නේ කුමක් ද
දොරටුවේ ඇති දේ
ප්‍රතිදානය කුමක්ද

සූදානම් කරන්න: පරීක්ෂණය සඳහා සූදානම් වීමේ අදියර

පැටවීමේ පරාමිතීන්
සැකසීම සහ ආරම්භ කිරීම
පරිශීලක
පැටවීමේ පරාමිතීන්,
මිනුම් තෝරා ගැනීම සහ
පරීක්ෂණ සැලැස්ම සකස් කිරීම
(පූරණය පැතිකඩ)
සඳහා අභිරුචි විකල්ප
පැටවුම් නියෝජිතයා ආරම්භ කිරීම
පරීක්ෂණ සැලැස්ම
පරීක්ෂණයේ අරමුණ

VM
වලාකුළු යෙදවීම
සමඟ අතථ්‍ය යන්ත්‍රය
අවශ්ය ලක්ෂණ
පැටවුම් නියෝජිතයා සඳහා VM සැකසුම්
සඳහා ස්වයංක්‍රීය ස්ක්‍රිප්ට්
VM නිර්මාණය
VM වින්‍යාස කර ඇත
වලාකුළු

එන්
OS සැකසීම සහ සකස් කිරීම
සඳහා පරිසරය
load agent වැඩ
සඳහා පරිසර සැකසුම්
පැටවුම් නියෝජිතයා
සඳහා ස්වයංක්‍රීය ස්ක්‍රිප්ට්
පරිසර සැකසුම්
සකස් කළ පරිසරය:
OS, සේවා සහ යෙදුම්,
වැඩ සඳහා අවශ්ය
පැටවුම් නියෝජිතයා

LoadAgents
ස්ථාපනය, මානකරනය සහ පරාමිතිකරණය
පැටවීමේ නියෝජිතයා.
නැතහොත් ඩොකර් රූපයක් බාගත කිරීම
පූර්ව වින්යාසගත පැටවුම් මූලාශ්රය
මූලාශ්‍ර ඩොකර් රූපය පූරණය කරන්න
(YAT, JM හෝ ස්වයං-ලිඛිත රාමුව)
සැකසුම්
පැටවුම් නියෝජිතයා
සකස් කර සූදානම්
වැඩ භාර නියෝජිතයා වෙත

පරීක්ෂණය: බර පරීක්ෂණ ක්රියාත්මක කිරීමේ අදියර. මූලාශ්‍ර යනු GitLab CI සඳහා කැප වූ නියෝජිත සංචිතවල යොදවා ඇති පැටවුම් නියෝජිතයන්ය.

පැටවීම
පැටවීමේ නියෝජිතයා ආරම්භ කිරීම
තෝරාගත් පරීක්ෂණ සැලැස්ම සමඟ
සහ පරාමිති පැටවීම
පරිශීලක විකල්ප
ආරම්භ කිරීම සඳහා
පැටවුම් නියෝජිතයා
පරීක්ෂණ සැලැස්ම
පරීක්ෂණයේ අරමුණ
ක්රියාත්මක කිරීමේ ලඝු-සටහන්
පැටවීමේ පරීක්ෂණ
පද්ධති ලොග
ඉලක්ක ප්‍රමිතික සහ භාර කාරකයේ වෙනස්වීම් වල ගතිකත්වය

නියෝජිතයන් ධාවනය කරන්න
නියෝජිත ක්රියාත්මක කිරීම
පරීක්ෂණ ස්ක්‍රිප්ට් ගොඩක්
එකඟත්වයෙන් යුතුව
පැතිකඩ පැටවීම
ලෝඩ් නියෝජිත අන්තර්ක්‍රියා
පරීක්ෂා කිරීමේ අරමුණ සඳහා
පරීක්ෂණ සැලැස්ම
පරීක්ෂණයේ අරමුණ

සටහන්
"අමු" ලඝු-සටහන් එකතුව
බර පරීක්ෂා කිරීමේදී:
පැටවීමේ නියෝජිත ක්‍රියාකාරකම් වාර්තා,
පරීක්ෂණ ඉලක්කයේ තත්වය
සහ නියෝජිතයා ක්රියාත්මක වන VM

ක්රියාත්මක කිරීමේ ලඝු-සටහන්
පැටවීමේ පරීක්ෂණ
පද්ධති ලොග

ප්රමිතික
පරීක්ෂණය අතරතුර "අමු" මිනුම් එකතු කිරීම

ඉලක්ක ප්‍රමිතිකවල වෙනස්වීම් වල ගතිකත්වය
සහ පැටවුම් නියෝජිතයා

වාර්තාව: පරීක්ෂණ වාර්තා සකස් කිරීමේ අදියර

ජනකය
සැකසුම් එකතු කරන ලදී
පැටවීමේ පද්ධතිය සහ
අධීක්ෂණ පද්ධතිය "අමු"
මිනුම් සහ ලඝු-සටහන්
තුළ වාර්තාවක් සැකසීම
මානව කියවිය හැකි ආකෘතිය
මූලද්රව්ය සමඟ හැකි ය
විශ්ලේෂකයෝ ය
ක්රියාත්මක කිරීමේ ලඝු-සටහන්
පැටවීමේ පරීක්ෂණ
පද්ධති ලොග
ප්‍රමිතික වෙනස්වීම් වල ගතිකත්වය
ඉලක්ක සහ පැටවුම් නියෝජිතයා
සැකසූ "අමු" ලඝු-සටහන්
සඳහා සුදුසු ආකෘතියකින්
බාහිර ගබඩාවට උඩුගත කරයි
ස්ථිතික පැටවුම් වාර්තාව,
මිනිසාට කියවිය හැකි

ප්රකාශයට පත් කරනු ලබයි
වාර්තාව ප්‍රකාශයට පත් කිරීම
පැටවීම ගැන
බාහිරව පරීක්ෂා කිරීම
සේවාව
සැකසූ "අමු"
සුදුසු ආකෘතියකින් ලොග් කරන්න
බාහිරට බෑම සඳහා
නිධි
බාහිරව සුරකින ලදී
මත ගබඩා වාර්තා
පැටවීම, සුදුසුය
මානව විශ්ලේෂණය සඳහා

CI අච්චුවක පැටවුම් මූලාශ්‍ර සම්බන්ධ කිරීම

අපි ප්‍රායෝගික කොටස වෙත යමු. මට සමාගමේ සමහර ව්‍යාපෘතිවල ආකාරය පෙන්වීමට අවශ්‍යයි ධනාත්මක තාක්ෂණයන් අපි සේවාවක් ලෙස බර පරීක්ෂා කිරීමේ සංකල්පය ක්‍රියාත්මක කර ඇත.

පළමුව, අපගේ DevOps ඉංජිනේරුවන්ගේ සහාය ඇතිව, අපි බර පරීක්ෂණ ක්‍රියාත්මක කිරීම සඳහා GitLab CI හි කැපවූ නියෝජිත සංචිතයක් නිර්මාණය කළෙමු. එකලස් කිරීමේ තටාක වැනි වෙනත් ඒවා සමඟ සැකිලි තුළ ඒවා පටලවා නොගැනීම සඳහා, අපි මෙම නියෝජිතයින්ට ටැග් එකතු කළෙමු, ටැග්ස්: පැටවීම. ඔබට වෙනත් තේරුම් ගත හැකි ටැග් භාවිතා කළ හැකිය. ඔවුන් අසයි ලියාපදිංචි කිරීමේදී GitLab CI ධාවකයන්.

දෘඪාංග මගින් අවශ්ය බලය සොයා ගන්නේ කෙසේද? පැටවුම් නියෝජිතයින්ගේ ලක්ෂණ - ප්රමාණවත් තරම් vCPU, RAM සහ තැටිය - නියෝජිතයා මත Docker, Python (Yandex.Tank සඳහා), GitLab CI නියෝජිතයා, Java (Apache JMeter සඳහා) ක්රියාත්මක විය යුතු බව මත පදනම්ව ගණනය කළ හැක. JMeter යටතේ ජාවා සඳහා, අවම වශයෙන් 512 MB RAM භාවිතා කිරීම සහ ඉහළ සීමාවක් ලෙස, 80% ලබා ගත හැකි මතකය.

මේ අනුව, අපගේ අත්දැකීම් මත පදනම්ව, පැටවීමේ නියෝජිතයන් සඳහා අවම වශයෙන් 4 vCPUs, 4 GB RAM, 60 GB SSD භාවිතා කිරීමට අපි නිර්දේශ කරමු. ලෝඩ් පැතිකඩෙහි අවශ්‍යතා මත පදනම්ව ජාල කාඩ්පතේ ප්‍රතිදානය තීරණය වේ.

අපි ප්‍රධාන වශයෙන් load sources දෙකක් භාවිතා කරමු - Apache JMeter සහ Yandex.Tank docker images.

Yandex.Tank load testing සඳහා Yandex වෙතින් විවෘත මූලාශ්‍ර මෙවලමකි. එහි මොඩියුලර් ගෘහ නිර්මාණ ශිල්පය Phantom හි ඉහළ ක්‍රියාකාරී අසමමුහුර්ත පහර-පාදක HTTP ඉල්ලීම් උත්පාදක යන්ත්‍රය මත පදනම් වේ. ටැංකිය SSH ප්‍රොටෝකෝලය හරහා පරීක්‍ෂාවට ලක්ව ඇති සේවාදායකයේ සම්පත් අධීක්‍ෂණය කර ඇත, නිශ්චිත කොන්දේසි යටතේ ස්වයංක්‍රීයව පරීක්ෂණය නැවැත්විය හැකිය, ප්‍රති results ල කොන්සෝලයේ සහ ප්‍රස්ථාර ආකාරයෙන් පෙන්විය හැකිය, ක්‍රියාකාරීත්වය පුළුල් කිරීම සඳහා ඔබේ මොඩියුල එයට සම්බන්ධ කළ හැකිය. මාර්ගය වන විට, එය තවමත් ප්රධාන ධාරාවේ නොතිබූ විට අපි ටැංකිය භාවිතා කළෙමු. ලිපියේ "Yandex.Tank සහ load testing automation» 2013 දී අපි එය සමඟ බර පරීක්ෂාව සිදු කළ ආකාරය පිළිබඳ කතාව ඔබට කියවිය හැකිය PT යෙදුම් ෆයර්වෝල් අපගේ සමාගමේ නිෂ්පාදන වලින් එකකි.

අපාචි ජේමීටර් Apache වෙතින් විවෘත මූලාශ්‍ර පැටවුම් පරීක්ෂණ මෙවලමකි. එය ස්ථිතික සහ ගතික වෙබ් යෙදුම් දෙකම පරීක්ෂා කිරීම සඳහා සමානව භාවිතා කළ හැක. JMeter විශාල ප්‍රොටෝකෝල ගණනකට සහ යෙදුම් සමඟ අන්තර් ක්‍රියා කිරීමට ක්‍රම සඳහා සහය දක්වයි: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ආදිය), SOAP / REST වෙබ් සේවා, FTP, TCP, LDAP, SMTP(S), POP3(S) සහ IMAP(S), දත්ත සමුදායන් සමඟින් ජායාරූප සමඟින් ක්‍රියා කළ හැක. JMeter සතුව පරීක්ෂණ සැලසුම් නිර්මාණය කිරීම, දෝෂහරණය කිරීම සහ ක්‍රියාත්මක කිරීම සඳහා IDE එකක් ඇත. ඕනෑම Java අනුකූල මෙහෙයුම් පද්ධතියක (Linux, Windows, Mac OS X) විධාන රේඛා ක්‍රියාකාරිත්වය සඳහා CLI එකක් ද ඇත. මෙවලමට ගතිකව HTML පරීක්ෂණ වාර්තාවක් ජනනය කළ හැක.

අපගේ සමාගම තුළ භාවිතයේ පහසුව සඳහා, පරිසරය වෙනස් කිරීමට සහ එකතු කිරීමට පරීක්ෂකයින්ට ඇති හැකියාව සඳහා, අපි අභ්‍යන්තරයට ප්‍රකාශනය කිරීමත් සමඟ GitLab CI මත පැටවුම් ප්‍රභවයන්ගේ ඩොකර් රූප ගොඩනඟමු. කෘතිම කර්මාන්ත ශාලාවේ ඩොකර් රෙජිස්ට්රි. බර පරීක්ෂණ සඳහා නල මාර්ගවල ඒවා සම්බන්ධ කිරීම වේගවත් හා පහසු කරයි. GitLab CI හරහා රෙජිස්ට්‍රියට ඩොකර් තල්ලු කරන්නේ කෙසේද - බලන්න උපදෙස්.

අපි Yandex.Tank සඳහා මෙම මූලික ඩොකර් ගොනුව ගත්තා:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

සහ Apache JMeter සඳහා මෙය:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

අපගේ අඛණ්ඩ ඒකාබද්ධ පද්ධතිය ක්‍රියා කරන ආකාරය ඔබට ලිපියෙන් කියවිය හැකිය "සංවර්ධන ක්‍රියාවලීන් ස්වයංක්‍රීයකරණය: ධනාත්මක තාක්ෂණයන්හිදී අපි DevOps අදහස් ක්‍රියාත්මක කළ ආකාරය".

සැකිල්ල සහ නල මාර්ගය

බර පරීක්ෂණ පැවැත්වීම සඳහා අච්චුවක උදාහරණයක් ව්‍යාපෘතියේ ඇත demo load. මෙම readme ගොනුව අච්චුව භාවිතා කිරීම සඳහා ඔබට උපදෙස් කියවිය හැකිය. අච්චුව තුළම (ගොනුව .gitlab-ci.yml) සෑම පියවරකටම වගකිව යුතු දේ පිළිබඳ සටහන් තිබේ.

අච්චුව ඉතා සරල වන අතර ඉහත රූප සටහනේ විස්තර කර ඇති බර පරීක්ෂා කිරීමේ අදියර තුන පෙන්නුම් කරයි: වාර්තා සකස් කිරීම, පරීක්ෂා කිරීම සහ ප්‍රකාශනය කිරීම. මේ සඳහා වගකිව යුතුය අදියර: සූදානම් කරන්න, පරීක්ෂා කරන්න සහ වාර්තා කරන්න.

1. අදියර සූදානම් වෙන්න පරීක්ෂණ ඉලක්ක පූර්ව වින්‍යාස කිරීමට හෝ ඒවායේ ඇති බව පරීක්ෂා කිරීමට භාවිතා කළ යුතුය. පැටවුම් ප්‍රභවයන් සඳහා පරිසරය වින්‍යාස කිරීම අවශ්‍ය නොවේ, ඒවා ඩොකර් රූප ලෙස පූර්ව-සාදන ලද අතර ඩොකර් රෙජිස්ට්‍රියේ පළ කර ඇත: පරීක්ෂණ අදියරේදී අවශ්‍ය අනුවාදය සඳහන් කරන්න. නමුත් ඔබට ඒවා නැවත ගොඩනඟා ඔබේම වෙනස් කළ පින්තූර සෑදිය හැකිය.
2. අදියර ටෙස්ට් බර ප්‍රභවය නියම කිරීමට, පරීක්ෂණ ධාවනය කිරීමට සහ පරීක්ෂණ කෞතුක වස්තු ගබඩා කිරීමට භාවිතා කරයි. ඔබට ඕනෑම පැටවුම් මූලාශ්රයක් තෝරාගත හැක: Yandex.Tank, Apache JMeter, ඔබේම, හෝ සියල්ල එකට. අනවශ්‍ය මූලාශ්‍ර අක්‍රිය කිරීමට, අදහස් දක්වන්න හෝ කාර්යය මකා දමන්න. පැටවුම් මූලාශ්ර සඳහා ඇතුල් වීමේ ස්ථාන:
   • Yandex.Tank සඳහා දියත් කිරීමේ පරාමිතීන් හි දක්වා ඇත./tests/yandextank.sh,
   • Apache JMeter ආරම්භක පරාමිතීන් ගොනුවේ දක්වා ඇත ./tests/jmeter.sh.

   සටහන: එකලස් කිරීමේ වින්‍යාස අච්චුව CI පද්ධතිය සමඟ අන්තර්ක්‍රියා සැකසීමට භාවිතා කරන අතර එහි පරීක්ෂණ තර්කය ස්ථානගත කිරීමක් අදහස් නොකරයි. පරීක්ෂණ සඳහා, පාලන බාෂ් ස්ක්‍රිප්ට් පිහිටා ඇති ප්‍රවේශ ලක්ෂ්‍යය නියම කර ඇත. පරීක්ෂණ ක්‍රියාත්මක කිරීමේ ක්‍රමය, වාර්තා උත්පාදනය කිරීම සහ පරීක්ෂණ ස්ක්‍රිප්ට් ක්‍රියාත්මක කිරීම QA ඉංජිනේරුවන් විසින් ක්‍රියාත්මක කළ යුතුය. ආදර්ශනයේ, පැටවුම් මූලාශ්ර දෙකම සඳහා, Yandex ප්රධාන පිටු ඉල්ලීම සරලම පරීක්ෂණය ලෙස භාවිතා කරයි. ස්ක්‍රිප්ට් සහ පරීක්ෂණ පරාමිති නාමාවලියෙහි ඇත ./පරීක්ෂණ.

3. වේදිකාවේදී වාර්තාව පරීක්ෂණ අදියරේදී ලබාගත් පරීක්ෂණ ප්‍රතිඵල බාහිර ගබඩාවලට, උදාහරණයක් ලෙස, GitLab පිටුවලට හෝ විශේෂ වාර්තාකරණ පද්ධතිවලට ප්‍රකාශයට පත් කරන්නේ කෙසේද යන්න ඔබට විස්තර කිරීමට අවශ්‍ය වේ. GitLab පිටු වලට ./public නාමාවලිය හිස් නොවිය යුතු අතර පරීක්ෂණ අවසන් වූ පසු අවම වශයෙන් index.html ගොනුවක්වත් අඩංගු විය යුතුය. GitLab Pages සේවාවේ සූක්ෂ්මතා ගැන ඔබට කියවිය හැකිය. ලින්ක්.

   දත්ත අපනයනය කරන ආකාරය පිළිබඳ උදාහරණ:

   • JMeter සිට GitLab පිටු,
   • Yandex.Tank සිට InfluxDB සහ Grafana.

   සැකසුම් උපදෙස් පළ කිරීම:

   • HTML ස්ථිතික තුළ GitLab පිටු,
   • InfluxDB වෙත සහ පසුව වෙත ග්‍රැෆනා.

ආදර්ශන උදාහරණයේ, බර පරීක්ෂණ සහ බර ප්‍රභව දෙකක් සහිත නල මාර්ගය (ඔබට අනවශ්‍ය එක අක්‍රිය කළ හැකිය) මේ වගේ ය:

Apache JMeter හට HTML වාර්තාවක් ජනනය කළ හැක, එබැවින් සම්මත මෙවලම් භාවිතයෙන් GitLab පිටු තුළ එය සුරැකීම වඩා ලාභදායී වේ. Apache JMeter වාර්තාව පෙනෙන ආකාරය මෙයයි:

Yandex.Tank සඳහා ආදර්ශන උදාහරණයේ, ඔබ පමණක් දකිනු ඇත ව්යාජ පෙළ වාර්තාව GitLab පිටු සඳහා කොටසේ. පරීක්ෂා කිරීමේදී, ටැංකියට ප්‍රතිඵල InfluxDB දත්ත ගබඩාවට සුරැකිය හැකි අතර, එතැන් සිට ඒවා ප්‍රදර්ශනය කළ හැක, උදාහරණයක් ලෙස, Grafana (වින්‍යාසය ගොනුවේ සිදු කෙරේ. ./tests/example-yandextank-test.yml) ටැංකියේ වාර්තාව ග්‍රැෆානා හි දිස්වන්නේ මෙසේය.

සාරාංශය

ලිපියේ මම කතා කළේ "භාර පරීක්ෂාව සේවාවක් ලෙස" (භාර පරීක්ෂාව සේවාවක් ලෙස) යන සංකල්පය ගැන ය. ප්‍රධාන අදහස නම්, පූර්ව වින්‍යාසගත කළ ලෝඩ් ඒජන්ට් සංචිතවල යටිතල පහසුකම්, බර ප්‍රභවයන්ගේ ඩොකර් රූප, වාර්තාකරණ පද්ධති සහ සරල .gitlab-ci.yml අච්චුවක් මත පදනම්ව GitLab CI තුළ ඒවා ඒකාබද්ධ කරන නල මාර්ගයක් භාවිතා කිරීමයි (උදාහරණ ලින්ක්) මේ සියල්ල ස්වයංක්‍රීය ඉංජිනේරුවන්ගේ කුඩා කණ්ඩායමක් විසින් සහාය දක්වන අතර නිෂ්පාදන කණ්ඩායම්වල ඉල්ලීම පරිදි ප්‍රතිනිර්මාණය කරනු ලැබේ. ඔබේ සමාගම තුළ සමාන යෝජනා ක්රමයක් සකස් කිරීම සහ ක්රියාත්මක කිරීම සඳහා මෙය ඔබට උපකාර වනු ඇතැයි මම බලාපොරොත්තු වෙමි. අවධානය යෙමු කළාට ස්තූතියි!

PS අපගේ සමාගමේ සේවාවක් ලෙස බර පරීක්ෂා කිරීමේ සංකල්පය ක්‍රියාත්මක කිරීම සඳහා තාක්ෂණික සහාය සඳහා මගේ සගයන් වන සර්ජි කුර්බනොව් සහ නිකොලායි යුසෙව්ට විශාල ස්තූතියක් පැවසීමට මට අවශ්‍යය.

කතෘ: තිමූර් ගිල්මුලින් - නියෝජ්ය Positive Technologies හි තාක්ෂණ හා සංවර්ධන ක්‍රියාවලි (DevOps) ප්‍රධානියා

මූලාශ්රය: www.habr.com